ASP.NET a webové nástroje pro Visual Studio 2013 – poznámky k verzi

  • Článek

od Microsoftu

Tento dokument popisuje vydání ASP.NET and Web Tools pro Visual Studio 2013.

Obsah

Nové funkce v ASP.NET and Web Tools pro Visual Studio 2013

Poznámky k instalaci

ASP.NET and Web Tools pro Visual Studio 2013 jsou součástí hlavního instalačního programu a můžete si je stáhnout tady.

Dokumentace

Kurzy a další informace o ASP.NET and Web Tools pro Visual Studio 2013 jsou k dispozici na webu ASP.NET.

Požadavky na software

ASP.NET and Web Tools vyžaduje Visual Studio 2013.

Nové funkce v ASP.NET and Web Tools pro Visual Studio 2013

Následující části popisují funkce, které byly zavedeny ve vydané verzi.

Jeden ASP.NET

S vydáním Visual Studio 2013 jsme udělali krok směrem ke sjednocení prostředí s používáním ASP.NET technologií, abyste mohli snadno kombinovat a shodovat ty, které chcete. Můžete například zahájit projekt pomocí MVC a později do projektu snadno přidat Web Forms stránky nebo vygenerovat webová rozhraní API v Web Forms projektu. Jedním z ASP.NET je usnadnit vám jako vývojáři dělat věci, které máte rádi, ASP.NET. Bez ohledu na to, jakou technologii zvolíte, můžete mít jistotu, že stavíte na důvěryhodné základní architektuře One ASP.NET.

Nové prostředí webového projektu

Vylepšili jsme prostředí vytváření nových webových projektů v Visual Studio 2013. V dialogovém okně Nový ASP.NET webový projekt můžete vybrat požadovaný typ projektu, nakonfigurovat libovolnou kombinaci technologií (Web Forms, MVC, webové rozhraní API), nakonfigurovat možnosti ověřování a přidat projekt testování částí.

Nový projekt ASP.NET

Nové dialogové okno umožňuje změnit výchozí možnosti ověřování pro mnoho šablon. Například při vytváření projektu ASP.NET Web Forms můžete vybrat některou z následujících možností:

  • Bez ověřování
  • Individuální uživatelské účty (ASP.NET členství nebo přihlášení poskytovatele sociálních sítí)
  • Účty organizace (Active Directory v internetové aplikaci)
  • Ověřování systému Windows (Active Directory v intranetové aplikaci)

Možnosti ověřování

Další informace o novém procesu vytváření webových projektů najdete v tématu Vytváření webových projektů ASP.NET v Visual Studio 2013. Další informace o nových možnostech ověřování najdete v části ASP.NET Identity dále v tomto dokumentu.

ASP.NET generování

ASP.NET Generování uživatelského rozhraní je rozhraní pro generování kódu pro ASP.NET webové aplikace. Umožňuje snadno přidat do projektu často používaný kód, který bude pracovat s datovým modelem.

V předchozích verzích sady Visual Studio bylo generování uživatelského rozhraní omezeno na projekty ASP.NET MVC. S Visual Studio 2013 teď můžete použít generování uživatelského rozhraní pro jakýkoli projekt ASP.NET, včetně Web Forms. Visual Studio 2013 v současné době nepodporuje generování stránek pro Web Forms projekt, ale i tak můžete použít generování uživatelského rozhraní s Web Forms přidáním závislostí MVC do projektu. Podpora generování stránek pro Web Forms bude přidána v budoucí aktualizaci.

Při použití generování uživatelského rozhraní zajistíme, aby v projektu byly nainstalovány všechny požadované závislosti. Pokud například začnete s projektem ASP.NET Web Forms a pak použijete generování uživatelského rozhraní k přidání kontroleru webového rozhraní API, přidají se do projektu automaticky požadované balíčky NuGet a odkazy.

Pokud chcete do projektu Web Forms přidat generování uživatelského rozhraní MVC, přidejte novou vygenerovanou položku a v dialogovém okně vyberte Závislosti MVC 5. Existují dvě možnosti pro generování uživatelského rozhraní MVC; Minimální a úplná. Pokud vyberete Minimální, přidají se do projektu jenom balíčky NuGet a odkazy pro ASP.NET MVC. Pokud vyberete možnost Úplné, přidají se minimální závislosti a také požadované soubory obsahu pro projekt MVC.

Podpora pro generování asynchronních kontrolerů využívá nové asynchronní funkce z Entity Frameworku 6.

Další informace a kurzy najdete v tématu ASP.NET Přehled generování uživatelského rozhraní.

Odkaz na prohlížeč – kanál SignalR mezi prohlížečem a sadou Visual Studio

Nová funkce Odkaz na prohlížeč umožňuje připojit k sadě Visual Studio více prohlížečů a aktualizovat je kliknutím na tlačítko na panelu nástrojů. K webu pro vývoj můžete připojit více prohlížečů, včetně mobilních emulátorů, a kliknutím na Aktualizovat aktualizovat všechny prohlížeče najednou. Odkaz na prohlížeč také zveřejňuje rozhraní API, které vývojářům umožňuje psát rozšíření Odkaz na prohlížeč.

Snímek obrazovky s nabídkou sady Visual Studio se zvýrazněnou ikonou Aktualizovat a zvýrazněným řídicím panelem Odkaz na prohlížeč v rozevírací nabídce

Tím, že vývojářům umožníte využívat výhod rozhraní API pro propojení s prohlížečem, je možné vytvářet velmi pokročilé scénáře, které překračují hranice mezi sadou Visual Studio a jakýmkoli připojeným prohlížečem. Web Essentials využívá rozhraní API k vytvoření integrovaného prostředí mezi sadou Visual Studio a vývojářskými nástroji prohlížeče, vzdáleným řízením mobilních emulátorů a mnoha dalšími funkcemi.

Vylepšení webového editoru sady Visual Studio

Visual Studio 2013 obsahuje nový editor HTML pro soubory Razor a soubory HTML ve webových aplikacích. Nový editor HTML poskytuje jediné jednotné schéma založené na HTML5. Má automatické dokončování závorek, uživatelské rozhraní jQuery a atribut AngularJS IntelliSense, atribut IntelliSense Grouping, ID a název třídy Intellisense a další vylepšení, včetně lepšího výkonu, formátování a smarttagů.

Následující snímek obrazovky ukazuje použití atributu Bootstrap IntelliSense v editoru HTML.

IntelliSense v editoru HTML

Visual Studio 2013 se také dodává s integrovanými editory CoffeeScript i LESS. Editor LESS se dodává se všemi skvělými funkcemi z editoru CSS a má specifickou intellisense pro proměnné a mixiny ve všech dokumentech LESS v řetězu @import .

Podpora Azure App Service Web Apps v sadě Visual Studio

V Visual Studio 2013 se sadou Azure SDK pro .NET 2.2 můžete k přímé interakci se vzdálenými webovými aplikacemi použít Průzkumníka serveru. Můžete se přihlásit ke svému účtu Azure, vytvářet nové webové aplikace, konfigurovat aplikace, zobrazovat protokoly v reálném čase atd. Brzy po vydání sady SDK 2.2 budete moct spustit v režimu ladění vzdáleně v Azure. Většina nových funkcí pro Azure App Service Web Apps fungovat také v sadě Visual Studio 2012 při instalaci aktuální verze sady Azure SDK pro .NET.

Další informace naleznete v následujících zdrojích:

Vylepšení publikování na webu

Visual Studio 2013 obsahuje nové a vylepšené funkce publikování na webu. Tady je několik z nich:

Další informace o nasazení webu ASP.NET naleznete na webu ASP.NET.

NuGet 2.7

NuGet 2.7 obsahuje bohatou sadu nových funkcí, které jsou podrobně popsané v poznámkách k verzi NuGet 2.7.

Tato verze NuGetu také odstraňuje potřebu poskytnutí výslovného souhlasu s funkcí obnovení balíčků NuGet ke stahování balíčků. Souhlas (a přidružené zaškrtávací políčko v dialogovém okně předvoleb NuGetu) se teď uděluje instalací NuGetu. Obnovení balíčku teď jednoduše funguje ve výchozím nastavení.

ASP.NET – webové formuláře

Jeden ASP.NET

Šablony projektů Web Forms se bezproblémově integrují s novým prostředím One ASP.NET. Do projektu Web Forms můžete přidat podporu MVC a webového rozhraní API a nakonfigurovat ověřování pomocí průvodce vytvořením jednoho ASP.NET projektu. Další informace najdete v tématu Vytváření webových projektů ASP.NET v Visual Studio 2013.

ASP.NET Identity

Šablony projektů Web Forms podporují novou architekturu ASP.NET Identity. Šablony teď navíc podporují vytvoření projektu Web Forms intranetu. Další informace najdete v tématu Metody ověřování v tématu Vytváření webových projektů ASP.NET v Visual Studio 2013.

Metoda bootstrap

Šablony Web Forms používají Bootstrap k tomu, aby poskytovaly elegantní a responzivní vzhled a chování, které si můžete snadno přizpůsobit. Další informace najdete v tématu Bootstrap v šablonách webových projektů Visual Studio 2013.

ASP.NET MVC 5

Jeden ASP.NET

Šablony projektů Web MVC se bezproblémově integrují s novým prostředím One ASP.NET. Projekt MVC si můžete přizpůsobit a nakonfigurovat ověřování pomocí průvodce vytvořením projektu One ASP.NET. Úvodní kurz k ASP.NET MVC 5 najdete na Začínáme s ASP.NET MVC 5.

Informace o upgradu projektů MVC 4 na MVC 5 najdete v tématu Postup upgradu ASP.NET MVC 4 a projektu webového rozhraní API na ASP.NET MVC 5 a webového rozhraní API 2.

ASP.NET Identity

Šablony projektů MVC byly aktualizovány tak, aby k ověřování a správě identit používaly ASP.NET Identity. Kurz s ověřováním na Facebooku a Googlu a novým rozhraním API pro členství najdete v tématech Vytvoření aplikace ASP.NET MVC 5 pomocí Facebooku a Google OAuth2 a Přihlášení OpenID a Vytvoření aplikace ASP.NET MVC s ověřováním a SQL DB a nasazení do Azure App Service.

Metoda bootstrap

Šablona projektu MVC byla aktualizována tak, aby používala bootstrap a poskytuje elegantní a responzivní vzhled a chování, které si můžete snadno přizpůsobit. Další informace najdete v tématu Bootstrap v šablonách webových projektů Visual Studio 2013.

Filtry ověřování

Ověřovací filtry představují nový druh filtru v ASP.NET MVC, který se spouští před filtry autorizace v kanálu ASP.NET MVC a umožňuje zadat logiku ověřování pro jednotlivé akce, kontroler nebo globálně pro všechny kontrolery. Filtry ověřování zpracovávají přihlašovací údaje v požadavku a poskytují odpovídající objekt zabezpečení. Filtry ověřování můžou také přidávat výzvy k ověřování v reakci na neautorizované požadavky.

Přepsání filtru

Teď můžete přepsat filtry, které se vztahují na danou metodu akce nebo kontroler, zadáním filtru přepsání. Přepsat filtry určují sadu typů filtrů, které by se neměly spouštět pro daný obor (akce nebo kontroler). To vám umožní konfigurovat filtry, které se použijí globálně, ale pak vyloučí určité globální filtry z použití na konkrétní akce nebo kontrolery.

Směrování atributů

ASP.NET MVC teď podporuje směrování atributů díky příspěvku Tima McCalla, autora http://attributerouting.net. Pomocí směrování atributů můžete určit trasy tak, že označíte akce a kontrolery.

Rozhraní API pro ASP.NET Web 2

Směrování atributů

ASP.NET webové rozhraní API teď podporuje směrování atributů díky příspěvku Tima McCalla, autora .http://attributerouting.net Pomocí směrování atributů můžete určit trasy webového rozhraní API tak, že označíte akce a kontrolery takto:

[RoutePrefix("orders")] 
public class OrdersController : ApiController 
{ 
    [Route("{id}")] 
    public Order Get(int id) { } 
    [Route("{id}/approve")] 
    public Order Approve(int id) { } 
}

Směrování atributů poskytuje větší kontrolu nad identifikátory URI ve webovém rozhraní API. Můžete například snadno definovat hierarchii prostředků pomocí jednoho kontroleru rozhraní API:

public class MoviesController : ApiController 
{ 
    [Route("movies")] 
    public IEnumerable<Movie> Get() { } 
    [Route("actors/{actorId}/movies")] 
    public IEnumerable<Movie> GetByActor(int actorId) { } 
    [Route("directors/{directorId}/movies")] 
    public IEnumerable<Movie> GetByDirector(int directorId) { } 
}

Směrování atributů také poskytuje pohodlnou syntaxi pro zadání volitelných parametrů, výchozích hodnot a omezení trasy:

// Optional parameter
[Route("people/{name?}")]
// Default value
[Route("people/{name=Dan}")]
// Constraint: Alphabetic characters only. 
[Route("people/{name:alpha}")]

Další informace o směrování atributů najdete v tématu Směrování atributů ve webovém rozhraní API 2.

OAuth 2.0

Šablony projektů Webové rozhraní API a Jednostránková aplikace teď podporují autorizaci pomocí OAuth 2.0. OAuth 2.0 je architektura pro autorizaci klientského přístupu k chráněným prostředkům. Funguje pro různé klienty, včetně prohlížečů a mobilních zařízení.

Podpora OAuth 2.0 je založená na novém middlewaru zabezpečení poskytovaném komponentami Microsoft OWIN pro ověřování nosné uživatele a implementaci role autorizačního serveru. Alternativně je možné klienty autorizovat pomocí autorizačního serveru organizace, jako je Azure Active Directory nebo ADFS v Windows Server 2012 R2.

Vylepšení OData

Podpora $select, $expand, $batch a $value

ASP.NET Web API OData teď nabízí plnou podporu pro $select, $expand a $value. Můžete také použít $batch k dávkování žádostí a zpracování sad změn.

Možnosti $select a $expand umožňují změnit tvar dat vrácených z koncového bodu OData. Další informace najdete v tématu Představujeme podporu $select a $expand ve webovém rozhraní API OData.

Vylepšená rozšiřitelnost

Formátovací moduly OData jsou teď rozšiřitelné. Můžete přidat metadata položky Atom, podporovat položky pojmenovaného streamu a multimediálního odkazu, přidat poznámky k instancím a přizpůsobit způsob generování odkazů.

Podpora bez typů

Teď můžete vytvářet služby OData, aniž byste museli definovat typy CLR pro vaše typy entit. Místo toho vaše kontrolery OData mohou přijmout nebo vrátit instance IEdmObject, které jsou OData formátování serialize/deserialize.

Opakované použití existujícího modelu

Pokud už máte existující model EDM (Entity Data Model), můžete ho teď znovu použít přímo a nemusíte vytvářet nový. Pokud například používáte Entity Framework, můžete použít EDM, který ef sestaví za vás.

Dávkování požadavků

Dávkování požadavků kombinuje více operací do jednoho požadavku HTTP POST, aby se snížil síťový provoz a poskytlo plynulejší a méně přehledné uživatelské rozhraní. ASP.NET webové rozhraní API teď podporuje několik strategií dávkování požadavků:

  • Použijte koncový bod $batch služby OData.
  • Zabalí několik požadavků do jedné vícedílné žádosti MIME.
  • Použijte vlastní formát dávkování.

Pokud chcete povolit dávkování požadavků, jednoduše přidejte trasu s obslužnou rutinou dávkování do konfigurace webového rozhraní API:

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
        config.Routes.MapHttpBatchRoute( 
            routeName: "WebApiBatch", 
            routeTemplate: "api/batch", 
            batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer)); 
    } 
}

Můžete také určit, jestli se požadavky provádějí postupně nebo v libovolném pořadí.

Přenosný klient webového rozhraní API ASP.NET

Pomocí klienta webového rozhraní API ASP.NET teď můžete vytvářet přenosné knihovny tříd, které fungují ve vašich aplikacích pro Windows Store a Windows Phone 8. Můžete také vytvořit přenosné formátovací moduly, které se dají sdílet mezi klientem a serverem.

Vylepšená testovatelnost

Webové rozhraní API 2 výrazně usnadňuje testování jednotek kontrolerů rozhraní API. Stačí vytvořit instanci kontroleru rozhraní API se zprávou požadavku a konfigurací a pak zavolat metodu akce, kterou chcete otestovat. Je také snadné napodobení třídy UrlHelper pro metody akcí, které provádějí generování odkazů.

IHttpActionResult

Teď můžete implementovat IHttpActionResult a zapouzdřovat výsledek metod akcí webového rozhraní API. Modul runtime webového rozhraní API vrátí hodnotu IHttpActionResult vrácenou metodou akce webového rozhraní API ASP.NET, aby se vygenerovala výsledná zpráva odpovědi. IHttpActionResult je možné vrátit z jakékoli akce webového rozhraní API, aby se zjednodušilo testování jednotek implementace webového rozhraní API. Pro usnadnění je k dispozici celá řada implementací IHttpActionResult, včetně výsledků pro vrácení konkrétních stavových kódů, formátovaného obsahu nebo vyjednaných odpovědí obsahu.

HttpRequestContext

Nový httpRequestContext sleduje všechny stavy, které jsou svázané s požadavkem, ale nejsou okamžitě dostupné z požadavku. Můžete například použít HttpRequestContext k získání dat trasy, objektu zabezpečení přidruženého k požadavku, klientského certifikátu, urlHelperu a kořenového adresáře virtuální cesty. Můžete snadno vytvořit HttpRequestContext pro účely testování jednotek.

Vzhledem k tomu, že objekt zabezpečení požadavku se teče s požadavkem, místo aby se spoléhal na Thread.CurrentPrincipal, je teď objekt zabezpečení k dispozici po celou dobu životnosti požadavku, když je v kanálu webového rozhraní API.

CORS

Díky dalšímu skvělému příspěvku Brock Allen, ASP.NET nyní plně podporuje sdílení žádostí mezi zdroji (CORS).

Zabezpečení prohlížečů brání webovým stránkám v odesílání požadavků AJAX na jinou doménu. CORS je standard W3C, který umožňuje serveru uvolnit zásady stejného původu. Pomocí CORS může server explicitně povolit některé požadavky mezi zdroji, zatímco jiné odmítnout.

Webové rozhraní API 2 teď podporuje CORS, včetně automatického zpracování předběžných požadavků. Další informace najdete v tématu Povolení požadavků mezi zdroji ve webovém rozhraní API ASP.NET.

Filtry ověřování

Filtry ověřování představují nový druh filtru ve webovém rozhraní API ASP.NET, který se spouští před filtry autorizace v kanálu webového rozhraní ASP.NET a umožňuje zadat logiku ověřování pro jednotlivé akce, kontroler nebo globálně pro všechny kontrolery. Ověřovací filtry zpracovávají přihlašovací údaje v požadavku a poskytují odpovídající objekt zabezpečení. Filtry ověřování také můžou v reakci na neautorizované požadavky přidávat problémy s ověřováním.

Přepsání filtru

Teď můžete přepsat, které filtry se vztahují na danou metodu nebo kontroler akce, zadáním filtru přepsání. Přepsat filtry určují sadu typů filtrů, které by se neměly spouštět pro daný obor (akce nebo kontroler). To vám umožní přidat globální filtry, ale pak některé vyloučit z konkrétních akcí nebo kontrolerů.

Integrace OWIN

ASP.NET webové rozhraní API teď plně podporuje OWIN a dá se spustit na libovolném hostiteli s podporou OWIN. Součástí je také filtr HostAuthenticationFilter , který poskytuje integraci s ověřovacím systémem OWIN.

Díky integraci OWIN můžete ve vlastním procesu hostovat webové rozhraní API společně s jiným middlewarem OWIN, jako je SignalR. Další informace najdete v tématu Použití OWIN k Self-Host ASP.NET webového rozhraní API.

ASP.NET SignalR 2.0

Následující části popisují funkce SignalR 2.0.

Příklad upgradu existujícího projektu 1.x na SignalR 2.0 najdete v tématu Upgrade projektu SignalR 1.x.

Postaveno na OWIN

SignalR 2.0 je zcela postaven na OWIN (open web interface for .NET). Díky této změně je proces nastavení služby SignalR mnohem konzistentnější mezi aplikacemi SignalR hostovanými na webu a v místním prostředí, ale vyžadoval také řadu změn rozhraní API.

MapHubs a MapConnection jsou teď MapSignalR.

Z důvodu kompatibility se standardy OWIN byly tyto metody přejmenovány na MapSignalR. MapSignalR volání bez parametrů namapuje všechna centra (jako MapHubs ve verzi 1.x). Pokud chcete mapovat jednotlivé objekty PersistentConnection , zadejte typ připojení jako parametr typu a jako první argument zadejte rozšíření url pro připojení.

Metoda MapSignalR je volána ve spouštěcí třídě Owin. Visual Studio 2013 obsahuje novou šablonu pro spouštěcí třídu Owin. Pokud chcete tuto šablonu použít, postupujte takto:

  1. Klikněte pravým tlačítkem na projekt.
  2. Vyberte Přidat, Nová položka...
  3. Vyberte Owin Startup class (Spouštěcí třída Owin). Pojmenujte novou třídu Startup.cs.

Ve webové aplikaci je pak spouštěcí třída Owin obsahující metodu MapSignalR přidána do spouštěcího procesu Owin pomocí položky v uzlu nastavení aplikace Web.Config souboru, jak je znázorněno níže.

V místní aplikaci je třída Startup předána jako parametr WebApp.Start typu metody.

Mapování center a připojení v SignalR 1.x (ze souboru globální aplikace ve webové aplikaci):

protected void Application_Start(object sender, EventArgs e) 
{
    // Map all hubs to "/signalr"
    RouteTable.Routes.MapHubs();
    // Map the Echo PersistentConnection to "/echo"
    RouteTable.Routes.MapConnection<myconnection>("echo", "/echo");
}

Mapování center a připojení v SignalR 2.0 (ze souboru třídy Owin Startup):

using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Map all hubs to "/signalr"
            app.MapSignalR();
            // Map the Echo PersistentConnection to "/echo"
            app.MapSignalR<echoconnection>("/echo");
        }
    }
}

V aplikaci v místním prostředí se třída Startup předává jako parametr typu pro metodu WebApp.Start , jak je znázorněno níže.

string url = "http://localhost:8080";
using (WebApp.Start<startup>(url))
{
    Console.WriteLine("Server running on {0}", url);
    Console.ReadLine();
}

Podpora napříč doménou

V SignalR 1.x byly požadavky mezi doménami řízeny jedním příznakem EnableCrossDomain. Tento příznak řídil požadavky JSONP i CORS. Kvůli větší flexibilitě byla ze serverové komponenty SignalR odebrána veškerá podpora CORS (klienti JavaScriptu stále používají CORS normálně, pokud se zjistí, že ho prohlížeč podporuje) a pro podporu těchto scénářů byl zpřístupněn nový middleware OWIN.

Pokud se v SignalR 2.0 vyžaduje na klientovi JSONP (kvůli podpoře požadavků mezi doménou ve starších prohlížečích), bude potřeba ho explicitně povolit nastavením EnableJSONP objektu HubConfiguration na truehodnotu , jak je znázorněno níže. JSONP je ve výchozím nastavení zakázaný, protože je méně bezpečný než CORS.

Pokud chcete přidat nový middleware CORS v SignalR 2.0, přidejte knihovnu Microsoft.Owin.Cors do projektu a zavolejte UseCors před middleware SignalR, jak je znázorněno v následující části.

Přidání Microsoft.Owin.Cors do projektu: Chcete-li nainstalovat tuto knihovnu, spusťte v konzole Správce balíčků následující příkaz:

Install-Package Microsoft.Owin.Cors

Tento příkaz přidá do projektu verzi balíčku 2.0.0.

Volání UseCors

Následující fragmenty kódu ukazují, jak implementovat připojení mezi doménami v SignalR 1.x a 2.0.

Implementace požadavků mezi doménou v SignalR 1.x (z globálního souboru aplikace)

protected void Application_Start(object sender, EventArgs e) 
{
    var hubConfiguration = new HubConfiguration();
    hubConfiguration.EnableCrossDomain = true;
    RouteTable.Routes.MapHubs(hubConfiguration);
}

Implementace požadavků mezi doménou v SignalR 2.0 (ze souboru kódu jazyka C#)

Následující kód ukazuje, jak povolit CORS nebo JSONP v projektu SignalR 2.0. Tento ukázkový kód používá Map a RunSignalR místo MapSignalR, takže middleware CORS běží jenom pro požadavky SignalR, které vyžadují podporu CORS (nikoli pro veškerý provoz na cestě zadané v MapSignalR. ) Map se dá použít také pro jakýkoli jiný middleware, který je potřeba spustit pro konkrétní předponu URL, a ne pro celou aplikaci.

using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Cors;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Branch the pipeline here for requests that start with "/signalr"
            app.Map("/signalr", map =>
            {
                // Setup the CORS middleware to run before SignalR.
                // By default this will allow all origins. You can 
                // configure the set of origins and/or http verbs by
                // providing a cors options with a different policy.
                map.UseCors(CorsOptions.AllowAll);
                var hubConfiguration = new HubConfiguration 
                {
                    // You can enable JSONP by uncommenting line below.
                    // JSONP requests are insecure but some older browsers (and some
                    // versions of IE) require JSONP to work cross domain
                    // EnableJSONP = true
                };
                // Run the SignalR pipeline. We're not using MapSignalR
                // since this branch already runs under the "/signalr"
                // path.
                map.RunSignalR(hubConfiguration);
            });
        }
    }
}

Podpora iOS a Androidu prostřednictvím MonoTouchu a MonoDroidu

Byla přidána podpora pro klienty s iOSem a Androidem, kteří používají komponenty MonoTouch a MonoDroid z knihovny Xamarin. Další informace o tom, jak je používat, najdete v tématu Použití komponent Xamarin. Tyto komponenty budou k dispozici v Xamarin Storu , až bude dostupná verze SignalR RTW.

### Přenosný klient .NET

Pro lepší usnadnění vývoje pro různé platformy byly klienty Silverlight, WinRT a Windows Phone nahrazeny jedním přenosným klientem .NET, který podporuje následující platformy:

  • NET 4.5
  • Silverlight 5
  • WinRT (.NET pro aplikace pro Windows Store)
  • Windows Phone 8

Nový balíček Self-Host

Nyní je k dispozici balíček NuGet, který usnadňuje zahájení práce s signalr Self-Host (aplikace SignalR, které jsou hostované v procesu nebo jiné aplikaci, a ne hostují se na webovém serveru). Pokud chcete upgradovat projekt s vlastním hostitelem sestavený pomocí SignalR 1.x, odeberte balíček Microsoft.AspNet.SignalR.Owin a přidejte balíček Microsoft.AspNet.SignalR.SelfHost. Další informace o tom, jak začít s balíčkem pro vlastní hostitele, najdete v tématu Kurz: SignalR Self-Host.

Podpora zpětně kompatibilních serverů

V předchozích verzích SignalR musely být verze balíčku SignalR použitého v klientovi a na serveru stejné. Aby bylo možné podporovat silné klientské aplikace, které by bylo obtížné aktualizovat, signalR 2.0 nyní podporuje použití novější verze serveru se starším klientem. Poznámka: SignalR 2.0 nepodporuje servery vytvořené ve starších verzích s novějšími klienty.

Odebrání podpory serveru pro .NET 4.0

SignalR 2.0 ukončil podporu interoperability serveru s .NET 4.0. .NET 4.5 se musí používat se servery SignalR 2.0. Pro SignalR 2.0 stále existuje klient .NET 4.0.

Odeslání zprávy do seznamu klientů a skupin

V SignalR 2.0 je možné odeslat zprávu pomocí seznamu ID klientů a skupin. Následující fragmenty kódu ukazují, jak to udělat.

Odeslání zprávy do seznamu klientů a skupin pomocí funkce PersistentConnection

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatConnection : PersistentConnection
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string>{"chatGroup", "chatGroup2"};
    protected override System.Threading.Tasks.Task OnReceived(IRequest request, string connectionId, string data)
    {
        Connection.Send(ConnectionIds, data);
        Groups.Send(groups, data);
        return base.OnReceived(request, connectionId, data);
    }
    protected override System.Threading.Tasks.Task OnConnected(IRequest request, string connectionId)
    {
        ConnectionIds.Add(connectionId);
        Groups.Add(connectionId, "chatGroup");
        return base.OnConnected(request, connectionId);
    }
    protected override System.Threading.Tasks.Task OnDisconnected(IRequest request, string connectionId)
    {
        ConnectionIds.Remove(connectionId);
        return base.OnDisconnected(request, connectionId);
    }
}

Odeslání zprávy do seznamu klientů a skupin pomocí Hubs

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatHub : Hub
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string> { "chatGroup", "chatGroup2" };
    public void Send(string name, string message)
    {
        // Call the broadcastMessage method to update clients.
        Clients.Clients(ConnectionIds).broadcastMessage(name, message);
        Clients.Groups(groups).broadcastMessage(name, message);
    }
    public override System.Threading.Tasks.Task OnConnected()
    {
        ConnectionIds.Add(Context.ConnectionId);
        Groups.Add(Context.ConnectionId, "chatGroup");
        return base.OnConnected();
    }
    public override System.Threading.Tasks.Task OnDisconnected()
    {
        ConnectionIds.Remove(Context.ConnectionId);
        return base.OnDisconnected();
    }
}

Odeslání zprávy konkrétnímu uživateli

Tato funkce umožňuje uživatelům určit, co je id uživatele na základě požadavku IRequest prostřednictvím nového rozhraní IUserIdProvider:

Rozhraní IUserIdProvider

public interface IUserIdProvider
{
    string GetUserId(IRequest request);
}

Ve výchozím nastavení bude existovat implementace, která jako uživatelské jméno používá IPrincipal.Identity.Name uživatele.

Ve službě Hubs budete moct posílat zprávy těmto uživatelům prostřednictvím nového rozhraní API:

Použití rozhraní Clients.User API

public class MyHub : Hub
{
    public void Send(string userId, string message)
    {
        Clients.User(userId).send(message);
    }
}

Lepší podpora zpracování chyb

Uživatelé teď můžou vyvolat výjimku HubException z jakéhokoli volání centra. Konstruktor HubException může přijmout řetězcovou zprávu a další data chyby objektu. SignalR automaticky serializuje výjimku a odešle ji klientovi, kde se použije k odmítnutí nebo selhání vyvolání metody centra.

Nastavení zobrazit podrobné výjimky centra nemá žádný vliv na HubException je odeslán zpět do klienta nebo ne; je vždy odeslán.

Kód na straně serveru demonstrující odeslání hubException klientovi

public class MyHub : Hub
{
    public void Send(string message)
    {
        if(message.Contains("<script>"))
        {
            throw new HubException("This message will flow to the client", new { user = Context.User.Identity.Name, message = message });
        }

        Clients.All.send(message);
    }
}

Javascriptový klientský kód demonstrující reakci na HubException odeslanou ze serveru

myHub.server.send("<script>")
            .fail(function (e) {
                if (e.source === 'HubException') {
                    console.log(e.message + ' : ' + e.data.user);
                }
            });

Kód klienta .NET demonstrující odpověď na HubException odeslanou ze serveru

try
{
    await myHub.Invoke("Send", "<script>");
}
catch(HubException ex)
{
    Conosle.WriteLine(ex.Message);
}

Jednodušší testování jednotek rozbočovačů

SignalR 2.0 obsahuje rozhraní s názvem IHubCallerConnectionContext ve službě Hubs, které usnadňuje vytváření napodobených volání na straně klienta. Následující fragmenty kódu ukazují použití tohoto rozhraní s oblíbenými testovacími svazky xUnit.net a moq.

Testování jednotek SignalR s xUnit.net

[Fact]
public void HubsAreMockableViaDynamic()
{
    bool sendCalled = false;
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    hub.Clients = mockClients.Object;
    dynamic all = new ExpandoObject();
    all.send = new Action<string>(message =>
    {
        sendCalled = true;
    });
    mockClients.Setup(m => m.All).Returns((ExpandoObject)all);
    hub.Send("foo");
    Assert.True(sendCalled);
}

Testování jednotek SignalR s moq

[Fact]
public interface IClientContract
{
    void send(string message);
}
public void HubsAreMockableViaType()
{
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    var all = new Mock<IClientContract>();
    hub.Clients = mockClients.Object;
    all.Setup(m => m.send(It.IsAny<string>())).Verifiable();
    mockClients.Setup(m => m.All).Returns(all.Object);
    hub.Send("foo");
    all.VerifyAll();

Zpracování chyb JavaScriptu

Ve službě SignalR 2.0 všechna zpětná volání chyb JavaScriptu vrací objekty chyb JavaScriptu místo nezpracovaných řetězců. To umožňuje službě SignalR tok rozsáhlejších informací do obslužných rutin chyb. Vnitřní výjimku můžete získat z source vlastnosti chyby.

Kód klienta JavaScriptu, který zpracovává výjimku Start.Fail

connection.start().fail(function(e) {
    console.log('The error is: ' + e.message);
});

ASP.NET Identity

Nový systém členství ASP.NET

ASP.NET Identity je nový systém členství pro ASP.NET aplikace. ASP.NET Identity usnadňuje integraci dat profilů specifických pro uživatele s daty aplikací. ASP.NET Identity také umožňuje zvolit model trvalosti pro profily uživatelů ve vaší aplikaci. Data můžete ukládat do SQL Server databáze nebo jiného úložiště dat, včetně úložišť dat NoSQL, jako jsou tabulky Azure Storage. Další informace najdete v tématu Jednotlivé uživatelské účty v tématu Vytváření webových projektů ASP.NET v Visual Studio 2013.

Ověřování na základě deklarací

ASP.NET teď podporuje ověřování na základě deklarací identity, kdy je identita uživatele reprezentována jako sada deklarací identity od důvěryhodného vystavitele. Uživatelé se můžou ověřovat pomocí uživatelského jména a hesla udržovaného v databázi aplikací nebo pomocí zprostředkovatelů sociálních identit (například Účty Microsoft, Facebook, Google, Twitter) nebo pomocí účtů organizace prostřednictvím Azure Active Directory nebo Active Directory Federation Services (AD FS) (ADFS).

Integrace se službou Azure Active Directory a Windows Server Active Directory

Teď můžete vytvářet ASP.NET projekty, které k ověřování používají Azure Active Directory nebo Windows Server Active Directory (AD). Další informace najdete v tématu Účty organizace v tématu Vytváření webových projektů ASP.NET v Visual Studio 2013.

Integrace OWIN

ASP.NET ověřování je teď založené na middlewaru OWIN, který je možné použít na jakémkoli hostiteli založeném na technologii OWIN. Další informace o OWIN naleznete v následující části Součásti Microsoft OWIN .

Komponenty Microsoft OWIN

Open Web Interface for .NET (OWIN) definuje abstrakci mezi webovými servery .NET a webovými aplikacemi. OWIN odděluje webovou aplikaci od serveru, takže webové aplikace jsou nezávislé na hostiteli. Můžete například hostovat webovou aplikaci založenou na OWIN ve službě IIS nebo ji sami hostovat ve vlastním procesu.

Změny zavedené v komponentách Microsoft OWIN (označovaných také jako projekt Katana) zahrnují nové komponenty serveru a hostitele, nové pomocné knihovny a middleware a nový middleware ověřování.

Další informace o OWIN a Kataně najdete v tématu Co je nového v OWIN a Kataně.

Poznámka: Aplikace OWIN nelze spustit v klasickém režimu služby IIS; musí být spuštěny v integrovaném režimu.

Poznámka: Aplikace OWIN musí běžet v plném vztahu důvěryhodnosti.

Nové servery a hostitelé

V této verzi byly přidány nové komponenty, které umožňují scénáře místního hostování. Mezi tyto komponenty patří následující balíčky NuGet:

  • Microsoft.Owin.Host.HttpListener. Poskytuje server OWIN, který používá HttpListener k naslouchání požadavkům HTTP a jejich směrování do kanálu OWIN.
  • Microsoft.Owin.Hosting Poskytuje knihovnu pro vývojáře, kteří chtějí sami hostovat kanál OWIN ve vlastním procesu, jako je konzolová aplikace nebo služba systému Windows.
  • OwinHost. Poskytuje samostatný spustitelný soubor, který zabalí Microsoft.Owin.Hosting a umožní vám vlastní hostování kanálu OWIN bez nutnosti psát vlastní hostitelskou aplikaci.

Balíček teď navíc umožňuje middlewaru Microsoft.Owin.Host.SystemWeb poskytovat nápovědu pro server SystemWeb , což znamená, že middleware by se měl volat během konkrétní fáze kanálu ASP.NET. Tato funkce je obzvláště užitečná pro ověřovací middleware, který by se měl spouštět v rané fázi kanálu ASP.NET.

Pomocné knihovny a middleware

I když můžete napsat komponenty OWIN pouze pomocí definic funkcí a typů ze specifikace OWIN, nový Microsoft.Owin balíček poskytuje uživatelsky přívětivější sadu abstrakcí. Tento balíček kombinuje několik dřívějších balíčků (např. Owin.Extensions, ) Owin.Typesdo jednoho dobře strukturovaného objektového modelu, který pak mohou snadno použít jiné komponenty OWIN. Ve skutečnosti většina komponent Microsoft OWIN nyní používá tento balíček.

Poznámka

Aplikace OWIN nelze spustit v klasickém režimu služby IIS; musí být spuštěny v integrovaném režimu.

Poznámka

Aplikace OWIN musí běžet v plném vztahu důvěryhodnosti.

Tato verze obsahuje také balíček Microsoft.Owin.Diagnostics, který obsahuje middleware pro ověření spuštěné aplikace OWIN, a middleware error-page, který pomáhá prozkoumat selhání.

Součásti ověřování

K dispozici jsou následující komponenty ověřování.

  • Microsoft.Owin.Security.ActiveDirectory. Umožňuje ověřování pomocí místních nebo cloudových adresářových služeb.
  • Microsoft.Owin.Security.Cookies Umožňuje ověřování pomocí souborů cookie. Tento balíček měl dříve název Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook Umožňuje ověřování pomocí služby Facebook založené na OAuth.
  • Microsoft.Owin.Security.Google Umožňuje ověřování pomocí služby Založené na OpenID společnosti Google.
  • Microsoft.Owin.Security.Jwt Povoluje ověřování pomocí tokenů JWT.
  • Microsoft.Owin.Security.MicrosoftAccount Umožňuje ověřování pomocí účtů Microsoft.
  • Microsoft.Owin.Security.OAuth. Poskytuje autorizační server OAuth a middleware pro ověřování nosných tokenů.
  • Microsoft.Owin.Security.Twitter Umožňuje ověřování pomocí služby twitterové technologie OAuth.

Tato verze obsahuje Microsoft.Owin.Cors také balíček , který obsahuje middleware pro zpracování požadavků HTTP mezi zdroji.

Poznámka

V konečné verzi Visual Studio 2013 jsme odebrali podporu podepisování JWT.

Entity Framework 6

Seznam nových funkcí a dalších změn v Entity Frameworku 6 najdete v historii verzí entity frameworku.

ASP.NET Razor 3

ASP.NET Razor 3 obsahuje následující nové funkce:

  • Podpora pro úpravy tabulátoru Dříve příkaz Formátovat dokument , automatické odsazení a automatické formátování v sadě Visual Studio při použití možnosti Zachovat záložky nefungoval správně. Tato změna opraví formátování v sadě Visual Studio pro kód Razor pro formátování tabulátoru.
  • Podpora pravidel přepsání adres URL při generování odkazů
  • Odebrání atributu transparentního zabezpečení

    Poznámka

    Jedná se o zásadní změnu, kvůli které razor 3 není kompatibilní s MVC4 a staršími verzemi, zatímco Razor 2 není kompatibilní s MVC5 nebo sestaveními zkompilovanými proti MVC5.

=======

Pozastavení aplikace ASP.NET

pozastavení aplikace ASP.NET je funkce měnící hry v rozhraní .NET Framework 4.5.1, která radikálně mění uživatelské prostředí a ekonomický model pro hostování velkého počtu webů ASP.NET na jednom počítači. Další informace najdete v tématu pozastavení aplikace ASP.NET – responzivní sdílené hostování webu .NET.

Známé problémy a zásadní změny

Tato část popisuje známé problémy a zásadní změny v ASP.NET and Web Tools pro Visual Studio 2013.

NuGet

  • Obnovení nového balíčku nefunguje v mono při použití souboru SLN – opravíme ho v nadcházející nuget.exe stažení a aktualizaci balíčku NuGet.CommandLine .
  • Obnovení nového balíčku nefunguje u projektů Wix – opravíme ho v nadcházející nuget.exe stažení a aktualizaci balíčku NuGet.CommandLine .

Rozhraní API pro ASP.NET Web

  1. ODataQueryOptions<T>.ApplyTo(IQueryable) nevrací IQueryable<T> vždy, protože jsme přidali podporu pro $select a $expand.

    Naše dřívější ukázky pro ODataQueryOptions<T> vždy přetypovaly návratnou hodnotu z ApplyTo na IQueryable<T>. Dříve to fungovalo, protože dříve podporované možnosti dotazu ($filter, $orderby, $skip, $top) nemění tvar dotazu. Teď, když podporujeme $select a $expand vrácená hodnota z ApplyTo nebude IQueryable<T> vždy.

    // Sample ODataQueryOptions<T> usage from earlier
public IQueryable<Customer> Get(ODataQueryOptions<Customer> query)
{
    IQueryable<customer> result="query.ApplyTo(_customers)" as iqueryable<customer>; return result;
}

    Pokud používáte vzorový kód z předchozích verzí, bude i nadále fungovat, pokud klient neodešle $select a $expand. Pokud ale chcete tento kód podporovat $select , $expand musíte ho na tento kód změnit.

    public IHttpActionResult Get(ODataQueryOptions<Customer> query)
{
    IQueryable result = query.ApplyTo(_customers);
    return Ok(result, result.GetType());
}
 
private IHttpActionResult Ok(object content, Type type)
{
    Type resultType = typeof(OkNegotiatedContentResult<>).MakeGenericType(type);
    return Activator.CreateInstance(resultType, content, this) as IHttpActionResult;
}

  2. Adresa Request.Url nebo RequestContext.Url má během dávkového požadavku hodnotu null.

    V dávkovém scénáři má UrlHelper při přístupu z Adresy Request.Url nebo RequestContext.Url hodnotu null.

    Alternativním řešením tohoto problému je vytvořit novou instanci UrlHelper, jak je znázorněno v následujícím příkladu:

    Vytvoření nové instance UrlHelper

    if (RequestContext.Url == null)
{
    RequestContext.Url = new UrlHelper(Request);
}

ASP.NET MVC

  1. Pokud používáte MVC5 a OrgAuth a máte zobrazení, která provádí ověřování AntiForgerToken, můžete při odesílání dat do zobrazení narazit na následující chybu:

    Chyba:

    Chyba serveru v aplikaci /.

    Deklarace identity typu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier nebo https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider nebyla přítomen u zadané identity ClaimsIdentity. Pokud chcete povolit podporu tokenů proti padělání s ověřováním na základě deklarací identity, ověřte, že nakonfigurovaný zprostředkovatel deklarací identity poskytuje obě tyto deklarace identity v instancích ClaimsIdentity, které generuje. Pokud nakonfigurovaný zprostředkovatel deklarací používá jako jedinečný identifikátor jiný typ deklarace identity, lze ho nakonfigurovat nastavením statické vlastnosti AntiForgeryConfig.UniqueClaimTypeIdentifier.

    Alternativní řešení:

    Opravte ho přidáním následujícího řádku v souboru Global.asax:

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Toto bude opraveno v příští verzi.

  2. Po upgradu aplikace MVC4 na MVC5 sestavte řešení a spusťte ho. Měla by se zobrazit následující chyba:

    [A] System.Web.WebPages.Razor.Configuration.HostSection nelze přetypovat na [B]System.Web.WebPages.Razor.Configuration.HostSection. Typ A pochází z 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' v kontextu 'Default' v umístění 'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. Typ B pochází z 'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' v kontextu 'Výchozí' v umístění 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6d05bbd0\e8b5908e\assembly\dl3\c9cbca63\f8910382_6273ce01\System.Web.WebPages.Razor.dll'.

    Pokud chcete vyřešit výše uvedenou chybu, otevřete všechny soubory Web.config (včetně souborů ve složce Zobrazení) ve vašem projektu a udělejte toto:

    1. Aktualizujte všechny výskyty verze 4.0.0.0 system.Web.Mvc na 5.0.0.0.

    2. Aktualizujte všechny výskyty verzí 2.0.0.0 pro System.Web.Helpers, System.Web.WebPages a System.Web.WebPages.Razor na 3.0.0.0.

      Například po provedení výše uvedených změn by vazby sestavení měly vypadat takto:

      <dependentAssembly>
  <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

      Informace o upgradu projektů MVC 4 na MVC 5 najdete v tématu Postup upgradu ASP.NET MVC 4 a projektu webového rozhraní API na ASP.NET MVC 5 a webového rozhraní API 2.

  3. Při použití ověřování na straně klienta s jQuery Unobttive Validation je ověřovací zpráva někdy nesprávná pro vstupní element HTML s type='number'. Chyba ověření pro požadovanou hodnotu ("Pole Věk je povinné") se zobrazí, když je zadáno neplatné číslo místo správné zprávy, že je požadováno platné číslo.

    K tomuto problému běžně dochází u vygenerovaného kódu pro model s celočíselnou vlastností v zobrazeníCh pro vytváření a úpravy.

    Pokud chcete tento problém obejít, změňte pomocnou rutinu editoru z:

    @Html.EditorFor(person => person.Age)

    Do:

    @Html.TextBoxFor(person => person.Age)

  4. ASP.NET MVC 5 už nepodporuje částečnou důvěryhodnost. Projekty odkazující na binární soubory MVC nebo WebAPI by měly odebrat atribut SecurityTransparent a atribut AllowPartiallyTrustedCallers . Odebráním těchto atributů se odstraní chyby kompilátoru, například následující.

    Attempt by security transparent method ‘MyComponent' to access security critical type 'System.Web.Mvc.MvcHtmlString' failed. Assembly 'PagedList.Mvc, Version=4.3.0.0, Culture=neutral, PublicKeyToken=abbb863e9397c5e1' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

    Poznámka: Jako vedlejší účinek tohoto nelze použít sestavení 4.0 a 5.0 ve stejné aplikaci. Všechny je potřeba aktualizovat na 5.0.

Šablona SPA s autorizací Facebook může způsobit nestabilitu v IE, když je web hostovaný v zóně intranetu.

Šablona SPA poskytuje externí přihlášení pomocí Facebooku. Pokud je projekt vytvořený pomocí šablony spuštěný místně, přihlášení může způsobit chybové ukončení aplikace IE.

Řešení:

  1. Hostovat web v internetové zóně; Nebo

  2. Otestujte scénář v jiném prohlížeči než IE.

Web Forms generování uživatelského rozhraní

Web Forms Generování uživatelského rozhraní bylo odebráno z VS2013 a bude k dispozici v budoucí aktualizaci sady Visual Studio. V rámci projektu Web Forms ale můžete dál používat generování uživatelského rozhraní přidáním závislostí MVC a generováním uživatelského rozhraní pro MVC. Projekt bude obsahovat kombinaci Web Forms a MVC.

Pokud chcete přidat MVC do projektu Web Forms, přidejte novou vygenerovanou položku a vyberte Závislosti MVC 5. Vyberte možnost Minimální nebo Úplná podle toho, jestli potřebujete všechny soubory obsahu, například skripty. Pak přidejte vygenerovanou položku pro MVC, která ve vašem projektu vytvoří zobrazení a kontroler.

Generování uživatelského rozhraní MVC a webového rozhraní API – chyba HTTP 404, Nenalezena

Pokud při přidávání vygenerované položky do projektu dojde k chybě, je možné, že projekt zůstane v nekonzistentním stavu. Některé z provedených změn vygenerování budou vráceny zpět, ale jiné změny, jako jsou nainstalované balíčky NuGet, se nevrátí zpět. Pokud se změny konfigurace směrování vrátí zpět, uživatelům se při přechodu na vygenerované položky zobrazí chyba HTTP 404.

Alternativní řešení:

  • Pokud chcete tuto chybu u MVC opravit, přidejte novou vygenerovanou položku a vyberte Závislosti MVC 5 (minimální nebo úplné). Tento proces přidá do projektu všechny požadované změny.

  • Oprava této chyby u webového rozhraní API:

    1. Přidejte do projektu třídu WebApiConfig.

      public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }
}

      Public Module WebApiConfig
    Public Sub Register(ByVal config As HttpConfiguration)
        config.MapHttpAttributeRoutes()
        config.Routes.MapHttpRoute(
          name:="DefaultApi",
          routeTemplate:="api/{controller}/{id}",
          defaults:=New With {.id = RouteParameter.Optional}
        )
    End Sub
End Module

    2. V metodě Application_Start v souboru Global.asax nakonfigurujte webApiConfig.Register následujícím způsobem:

      public class WebApiApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        GlobalConfiguration.Configure(WebApiConfig.Register);    
    }
}

      Public Class WebApiApplication
     Inherits System.Web.HttpApplication
 
     Sub Application_Start()     
       GlobalConfiguration.Configure(AddressOf WebApiConfig.Register)       
     End Sub
End Class