Sdílet prostřednictvím

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

  • Článek

podle Microsoftu

Tento dokument popisuje vydání ASP.NET a webových nástrojů pro Visual Studio 2013.

Obsah

Nové funkce v ASP.NET a webových nástrojích pro Visual Studio 2013

Poznámky k instalaci

ASP.NET a webové nástroje pro Visual Studio 2013 jsou součástí hlavního instalačního programu a lze je stáhnout zde.

Dokumentace

Kurzy a další informace o ASP.NET a webových nástrojích pro Visual Studio 2013 jsou k dispozici na webu ASP.NET.

Požadavky na software

ASP.NET a webové nástroje vyžadují Visual Studio 2013.

Nové funkce v ASP.NET a webových nástrojích pro Visual Studio 2013

Následující části popisují funkce, které byly představeny v této verzi.

Jeden ASP.NET

S vydáním sady Visual Studio 2013 jsme provedli krok k sjednocení zkušeností s používáním ASP.NET technologií, abyste mohli snadno kombinovat a shodovat s těmi, které chcete. Můžete například spustit projekt pomocí MVC a snadno přidat stránky webových formulářů do projektu později nebo vygenerovat webová rozhraní API v projektu Webových formulářů. Jedním ASP.NET je, že vám jako vývojář usnadní práci s tím, co v ASP.NET milujete. 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 možnosti vytváření nových webových projektů v sadě Visual Studio 2013. V dialogovém okně Nový ASP.NET Webový projekt můžete vybrat požadovaný typ projektu, nakonfigurovat libovolnou kombinaci technologií (Webové formuláře, MVC, webové rozhraní API), nakonfigurovat možnosti ověřování a přidat projekt testu jednotek.

Nový projekt ASP.NET

Nové dialogové okno umožňuje změnit výchozí možnosti ověřování pro mnoho šablon. Když například vytvoříte projekt ASP.NET Webových formulářů, můžete vybrat některou z následujících možností:

  • Bez ověřování
  • Jednotlivé 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ých možnostech ověřování najdete v části ASP.NET Identita dále v tomto dokumentu.

generování uživatelského rozhraní ASP.NET

ASP.NET generování uživatelského rozhraní je rozhraní pro generování kódu pro webové aplikace ASP.NET. Usnadňuje přidání často používaného kódu do projektu, který komunikuje 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. V sadě Visual Studio 2013 teď můžete používat generování uživatelského rozhraní pro libovolný ASP.NET projekt, včetně webových formulářů. Visual Studio 2013 v současné době nepodporuje generování stránek pro projekt Webových formulářů, ale můžete stále používat generování uživatelského rozhraní s webovými formuláři přidáním závislostí MVC do projektu. Podpora generování stránek pro webové formuláře bude přidána v budoucí aktualizaci.

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

Pokud chcete do projektu webových formulářů 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; Minimum a Plný. Pokud vyberete Minimum, do projektu se přidají 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 generování asynchronních kontrolerů použí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 více prohlížečů k sadě Visual Studio a aktualizovat je všechny kliknutím na tlačítko na panelu nástrojů. K vývojovému webu, včetně mobilních emulátorů, můžete připojit několik prohlížečů a kliknutím na 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 odkazu prohlížeče v rozevírací nabídce

Díky tomu, že vývojářům umožníte využívat rozhraní API pro propojení prohlížečů, je možné vytvořit velmi pokročilé scénáře, které překračují hranice mezi sadou Visual Studio a libovolným 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 ovládáním mobilních emulátorů a mnohem více.

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 jedno jednotné schéma založené na HTML5. Obsahuje automatické dokončování závorek, uživatelské rozhraní jQuery a atribut AngularJS IntelliSense, seskupení atributů IntelliSense, ID a název třídy Intellisense a další vylepšení, včetně lepšího výkonu, formátování a smartTags.

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

IntelliSense v editoru HTML

Součástí sady Visual Studio 2013 jsou také integrované editory CoffeeScript i LESS. Editor LESS se dodává se všemi skvělými funkcemi editoru CSS a má specifickou technologii IntelliSense pro proměnné a mixiny ve všech dokumentech LESS v řetězci @import .

Podpora webových aplikací služby Aplikace Azure v sadě Visual Studio

V sadě Visual Studio 2013 se sadou Azure SDK pro .NET 2.2 můžete pomocí Průzkumníka serveru pracovat přímo se vzdálenými webovými aplikacemi. Můžete se přihlásit ke svému účtu Azure, vytvořit nové webové aplikace, nakonfigurovat aplikace, zobrazit protokoly v reálném čase a provádět další možnosti. Brzy po vydání sady SDK 2.2 budete moct v Azure vzdáleně spouštět v režimu ladění. Většina nových funkcí pro Aplikace Azure Service Web Apps funguje 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í webu

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

  • Snadno automatizujte šifrování souborů Web.config. (Tento odkaz a následující dva body dokumentace na webu MSDN, které nemusí být dostupné až do konce dne 10.17.)
  • Snadné automatizace přechodu aplikace do offline režimu během nasazení
  • Nakonfigurujte nasazení webu tak, aby místo data poslední změny používalo kontrolní součet souborů pro určení souborů, které se mají zkopírovat na server.
  • Rychlé publikování jednotlivých vybraných souborů (včetně web.config) při použití metod publikování FTP nebo systému souborů a nasazení webu

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

NuGet 2.7

NuGet 2.7 obsahuje bohatou sadu nových funkcí, které jsou podrobně popsány ve zprávě k vydání verze NuGet 2.7.

Tato verze NuGetu také eliminuje nutnost poskytnout explicitní souhlas 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ů Webových formulářů se bezproblémově integrují s novým prostředím one ASP.NET. Do projektu webových formulářů můžete přidat podporu MVC a webového rozhraní API a ověřování můžete nakonfigurovat pomocí průvodce vytvořením projektu One ASP.NET.

ASP.NET Identity

Šablony projektů Webových formulářů podporují novou architekturu ASP.NET Identity. Kromě toho šablony nyní podporují vytváření intranetového projektu webových formulářů.

Bootstrap

Šablony webových formulářů používají Bootstrap k zajištění elegantního a responzivního vzhledu a chování, které můžete snadno přizpůsobit.

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 můžete přizpůsobit a nakonfigurovat ověřování pomocí průvodce vytvořením projektu One ASP.NET. Úvodní kurz ASP.NET MVC 5 najdete na webu Začínáme s ASP.NET MVC 5.

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

ASP.NET Identity

Šablony projektů MVC byly aktualizovány tak, aby používaly identitu ASP.NET pro ověřování a správu identit. Kurz s ověřováním Facebookem a Googlem a novým rozhraním API členství najdete v tématu Vytvoření aplikace ASP.NET MVC 5 s Facebookem a Google OAuth2 a přihlášením OpenID a vytvořením aplikace ASP.NET MVC s ověřováním a DATABÁZÍ SQL a nasazením do služby Aplikace Azure Service.

Bootstrap

Šablona projektu MVC byla aktualizována tak, aby poskytovala elegantní a responzivní vzhled a chování, které můžete snadno přizpůsobit.

Filtry ověřování

Ověřovací filtry jsou novým druhem filtru v ASP.NET MVC, který se spouští před autorizačními filtry v kanálu ASP.NET MVC a umožňuje zadat logiku ověřování podle akce, kontroleru 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í můžou také v reakci na neoprávněné požadavky přidávat problémy s ověřováním.

Přepsání filtrů

Teď můžete přepsat, které filtry 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 neměly být spuštěny pro daný obor (akce nebo kontroler). To vám umožní nakonfigurovat filtry, které platí globálně, ale pak některé globální filtry vyloučit z použití na konkrétní akce nebo kontrolery.

Směrování atributů

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

Rozhraní API pro ASP.NET Web 2

Směrování atributů

ASP.NET webové rozhraní API nyní podporuje směrování atributů díky příspěvku Tima McCalla, autora http://attributerouting.net. Pomocí směrování atributů můžete zadat trasy webového rozhraní API tak, že akce a kontrolery označíte 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. Hierarchii prostředků můžete například snadno definovat 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ávání volitelných parametrů, výchozích hodnot a omezení tras:

// 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ů naleznete v tématu Směrování atributů ve webovém rozhraní API 2.

OAuth 2.0

Šablony projektů webového rozhraní API a jednostrákové aplikace teď podporují autorizaci pomocí OAuth 2.0. OAuth 2.0 je architektura pro autorizaci přístupu klienta k chráněným prostředkům. Funguje pro celou řadu klientů, včetně prohlížečů a mobilních zařízení.

Podpora pro OAuth 2.0 je založená na novém middlewaru zabezpečení poskytovaném komponentami Microsoft OWIN pro ověřování nosné a implementaci role autorizačního serveru. Případně můžou být klienti autorizovaní pomocí autorizačního serveru organizace, jako je Azure Active Directory nebo ADFS ve Windows Serveru 2012 R2.

Vylepšení OData

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

ASP.NET OData webového rozhraní API teď plně podporuje $select, $expand a $value. Můžete také použít $batch pro 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 naleznete v tématu Úvod $select a $expand podporu ve webovém rozhraní API OData.

Vylepšená rozšiřitelnost

Formátovací moduly OData jsou nyní rozšiřitelné. Můžete přidat metadata položky Atom, podporovat pojmenované streamy a položky odkazu na média, přidat poznámky instance a přizpůsobit způsob generování odkazů.

Podpora bez typu

Teď můžete vytvářet služby OData, aniž byste museli definovat typy CLR pro vaše typy entit. Místo toho mohou kontrolery OData přijímat nebo vracet instance IEdmObject, což jsou formátovací moduly OData serializovat/deserializovat.

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

Pokud už máte existující datový model entity (EDM), 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 sestavuje za vás.

Vyžádání dávkování

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

  • Použijte koncový bod $batch služby OData.
  • Zabalte více požadavků do jednoho požadavku MIME s více částmi.
  • Použijte vlastní formát dávkování.

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

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é řídit, jestli se požadavky provádějí postupně nebo v libovolném pořadí.

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

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

Vylepšená testovatelnost

Webové rozhraní API 2 usnadňuje testování kontrolerů rozhraní API. Stačí vytvořit instanci kontroleru rozhraní API se zprávou žádosti 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í propojení.

IHttpActionResult

Teď můžete implementovat IHttpActionResult pro zapouzdření výsledku metod akcí webového rozhraní API. Metoda akce webového rozhraní API vrácená metodou akce IHttpActionResult je spuštěna modulem runtime webového rozhraní API ASP.NET za účelem vytvoření výsledné zprávy odpovědi. Z jakékoli akce webového rozhraní API lze vrátit IHttpActionResult, 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 odpovědí vyjednaných obsahem.

HttpRequestContext

Nový HttpRequestContext sleduje jakýkoli stav, který je svázán s požadavkem, ale není okamžitě k dispozici z požadavku. Pomocí httpRequestContext můžete například získat směrovací data, objekt zabezpečení přidružený k požadavku, klientský certifikát, UrlHelper a kořen virtuální cesty. Pro účely testování jednotek můžete snadno vytvořit HttpRequestContext .

Vzhledem k tomu, že objekt zabezpečení pro požadavek se provádí s požadavkem místo toho, aby se spoléhal na Thread.CurrentPrincipal, je teď objekt zabezpečení dostupný po celou dobu životnosti požadavku, zatímco je v kanálu webového rozhraní API.

CORS

Díky dalšímu skvělému příspěvku od 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 a zároveň odmítnout jiné.

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 v ASP.NET webovém rozhraní API.

Filtry ověřování

Ověřovací filtry jsou novým druhem filtru ve webovém rozhraní API ASP.NET, které se spouští před autorizačními filtry v kanálu webového rozhraní API ASP.NET a umožňují 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í můžou také v reakci na neoprávněné 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 akce nebo kontroler, zadáním filtru přepsání. Přepsání filtrů určuje sadu typů filtrů, které by se neměly spouštět pro daný obor (akci nebo kontroler). To vám umožní přidat globální filtry, ale pak některé z konkrétních akcí nebo kontrolerů vyloučit.

Integrace OWIN

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

Díky integraci OWIN můžete vlastní webové rozhraní API hostovat ve vlastním procesu spolu s jiným middlewarem OWIN, jako je SignalR. Další informace naleznete v tématu Použití OWIN k samoobslužné hostování ASP.NET webové 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 postaven zcela 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ých na webu a v místním prostředí, ale vyžadoval také řadu změn rozhraní API.

MapHubs a MapConnection jsou teď MapSignalR

Kvůli kompatibilitě se standardy OWIN byly tyto metody přejmenovány na MapSignalR. MapSignalR volání bez parametrů mapuje všechna centra (stejně jako MapHubs ve verzi 1.x); pro mapování jednotlivých objektů PersistentConnection , zadejte typ připojení jako parametr typu a rozšíření ADRESY URL pro připojení jako první argument.

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 použít tuto šablonu, postupujte takto:

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

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

V aplikaci v místním prostředí je třída Startup předána jako typ parametru WebApp.Start metody.

Mapování center a připojení v SignalR 1.x (z globálního souboru 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í rozbočovačů 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 metoduWebApp.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 napříč doménami řízeny jedním příznakem EnableCrossDomain. Tento příznak řídí požadavky JSONP i CORS. Kvůli větší flexibilitě se veškerá podpora CORS odebrala ze serverové komponenty SignalR (javascriptoví klienti stále používají CORS normálně, pokud zjistí, že ho prohlížeč podporuje) a pro podporu těchto scénářů byl zpřístupněn nový middleware OWIN.

V SignalR 2.0 se v klientovi vyžaduje JSONP (pro podporu požadavků napříč doménou ve starších prohlížečích), bude nutné ho explicitně povolit nastavením EnableJSONP objektu HubConfiguration truena hodnotu , jak je znázorněno níže. JsonP je ve výchozím nastavení zakázaný, protože je méně zabezpečený než CORS.

Pokud chcete přidat nový middleware CORS v SignalR 2.0, přidejte do projektu knihovnu Microsoft.Owin.Cors 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 Knihovně SignalR 1.x (ze souboru globální 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 Knihovně 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 vzorový kód používá Map a RunSignalR ne MapSignalRproto, aby middleware CORS běžel pouze pro požadavky SignalR, které vyžadují podporu CORS (nikoli pro veškerý provoz v cestě určené v MapSignalR.) Map lze použít také pro jakýkoli jiný middleware, který musí běžet pro konkrétní předponu adresy 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 pro iOS a Android prostřednictvím MonoTouchu a MonoDroidu

Byla přidána podpora pro klienty iOS a Android pomocí komponent 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, jakmile bude k dispozici 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 samoobslužného hostitele

Teď je k dispozici balíček NuGet, který usnadňuje zahájení práce s místním hostitelem SignalR (aplikace SignalR hostované v procesu nebo jiné aplikaci, nikoli hostované na webovém serveru). Pokud chcete upgradovat projekt místního hostitele vytvořený 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 self-host, naleznete v kurzu : SignalR Self-Host.

Podpora zpětně kompatibilních serverů

V předchozích verzích signalR se verze balíčku SignalR použitého v klientovi a serveru musely shodovat. 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é se staršími verzemi s novějšími klienty.

Odebrání podpory serveru pro .NET 4.0

SignalR 2.0 ukončil podporu pro interoperabilitu serverů s .NET 4.0. .NET 4.5 se musí používat se servery SignalR 2.0. Stále existuje klient .NET 4.0 pro SignalR 2.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 založené na IRequest prostřednictvím nového rozhraní IUserIdProvider:

Rozhraní IUserIdProvider

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

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

V centrech budete moct odesí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 vyvolání centra. Konstruktor HubException může přijmout řetězcovou zprávu a další data o chybě 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í podrobných výjimek rozbočovače nemá žádný vliv na odesílání hubException zpět klientovi, nebo ne. Vždy se odesílá.

Serverový kód 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);
    }
}

Kód klienta JavaScriptu demonstrující reakci na hubException odeslaný ze serveru

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

Kód klienta .NET, který demonstruje odpověď na hubException odeslaný 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í volané IHubCallerConnectionContext ve službě Hubs, které usnadňuje vytváření volání na straně klienta. Následující fragmenty kódu ukazují použití tohoto rozhraní s oblíbenými testovacími nástroji xUnit.net a moq.

SignalR testování jednotek s využitím 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);
}

Unit testing SignalR with 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

V SignalR 2.0 vrátí všechny javascriptové chyby zpracování zpětného volání javascriptové chybové objekty 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 aplikace ASP.NET. 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 profilů uživatelů ve vaší aplikaci. Data můžete uložit do databáze SQL Serveru nebo do jiného úložiště dat, včetně úložišť dat NoSQL, jako jsou tabulky Azure Storage. Další informace naleznete v tématu Jednotlivé uživatelské účty při vytváření ASP.NET webových projektů v sadě Visual Studio 2013.

Ověřování na základě deklarované identity

ASP.NET teď podporuje ověřování na základě deklarací identity, kde je identita uživatele reprezentovaná 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 spravovaného v aplikační databázi nebo pomocí zprostředkovatelů sociálních identit (například účty Microsoft, Facebook, Google, Twitter) nebo účty 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 naleznete v tématu Účty organizace při vytváření ASP.NET webových projektů v sadě 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 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é také jako projekt Katana) zahrnují nové serverové a hostitelské komponenty, nové pomocné knihovny a middleware a nový middleware ověřování.

Další informace o OWIN a Katana naleznete v tématu Co je nového v OWIN a Katana.

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ýt spuštěny 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 samoobslužného hostitele. 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ů HTTP a nasměruje je do kanálu OWIN.
  • Microsoft.Owin.Hosting poskytuje knihovnu vývojářům, kteří chtějí vlastního procesu hostovat kanál OWIN, jako je konzolová aplikace nebo služba Systému Windows.
  • OwinHost. Poskytuje samostatný spustitelný soubor, který se zabalí Microsoft.Owin.Hosting a umožňuje vlastní hostování kanálu OWIN bez nutnosti psát vlastní hostitelskou aplikaci.

Kromě toho Microsoft.Owin.Host.SystemWeb teď tento balíček umožňuje middlewaru poskytnout nápovědu k serveru SystemWeb , který indikuje, ž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 middleware ověřování, který by měl běžet v rané fázi kanálu ASP.NET.

Pomocné knihovny a middleware

I když můžete psát komponenty OWIN pouze pomocí definice funkce a typu 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.Types) do jediného dobře strukturovaného objektového modelu, který pak lze snadno použít jinými komponentami 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ýt spuštěny v plném vztahu důvěryhodnosti.

Tato verze obsahuje také balíček Microsoft.Owin.Diagnostics, který zahrnuje middleware k ověření spuštěné aplikace OWIN a middlewaru chybové stránky, který pomáhá prošetřit chyby.

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 byl dříve pojmenován Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook umožňuje ověřování pomocí služby založené na OAuth na Facebooku.
  • Microsoft.Owin.Security.Google umožňuje ověřování pomocí služby založené na OpenID společnosti Google.
  • Microsoft.Owin.Security.Jwt Umožňuje 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 i middleware pro ověřování nosných tokenů.
  • Microsoft.Owin.Security.Twitter umožňuje ověřování pomocí služby OAuth na Twitteru.

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

Poznámka:

Podpora podepisování JWT byla odebrána v konečné verzi sady Visual Studio 2013.

Entity Framework 6

Seznam nových funkcí a dalších změn v sadě Entity Framework 6 najdete v tématu Historie verzí entity Framework.

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 tabulátory nefungoval správně. Tato změna opravuje formátování sady 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 a zkompiluje Razor 3 nekompatibilní 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

ASP.NET Pozastavení aplikace je funkce pro změnu 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 ASP.NET webů na jednom počítači. Další informace najdete v tématu ASP.NET Pozastavení aplikace – responzivní sdílené hostování webů .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 a webových nástrojích pro Visual Studio 2013.

NuGet

  • Při použití souboru SLN nefunguje nové obnovení balíčku Mono – bude opraveno v nadcházejícím nuget.exe stažení a aktualizaci balíčku NuGet.CommandLine.
  • Obnovení nového balíčku nefunguje s projekty Wix – bude opraveno 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) se nevrací IQueryable<T> vždy, protože jsme přidali podporu pro $select a $expand.

    Naše dřívější vzorky pro ODataQueryOptions<T> vždy přetypování návratové hodnoty od ApplyTo do IQueryable<T>. To fungovalo dříve, protože možnosti dotazu, které jsme dříve podporovali ($filter, $orderby, $skip) $topnemění tvar dotazu. Teď, když podporujeme $select a $expand návratová 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 dřívější verze, bude pokračovat v práci, pokud klient neodesílá $select a $expand. Pokud ale chcete podporovat $select a $expand musíte tento kód změnit na tento.

    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. Request.Url nebo RequestContext.Url má během dávkového požadavku hodnotu null.

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

    Alternativním řešením tohoto problému je vytvoření nové instance UrlHelperu, jak je znázorněno v následujícím příkladu:

    Vytvoření nové instance urlHelperu

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

ASP.NET MVC

  1. Pokud používáte MVC5 a OrgAuth, pokud máte zobrazení, která mají AntiForgerToken ověřování, může při publikování dat do zobrazení dojít k následující chybě:

    Chyba:

    Chyba serveru v aplikaci /.

    Deklarace typu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier nebo https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider nebyla k dispozici u poskytnuté identity ClaimsIdentity. Pokud chcete povolit podporu tokenu 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 pro instance ClaimsIdentity, které generuje. Pokud nakonfigurovaný zprostředkovatel deklarací identity místo toho používá jiný typ deklarace identity jako jedinečný identifikátor, lze jej nakonfigurovat nastavením statické vlastnosti AntiForgeryConfig.UniqueClaimTypeIdentifier.

    Alternativní řešení:

    Pokud chcete tento problém opravit, přidejte do souboru Global.asax následující řádek:

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Toto bude opraveno pro 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.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í) v projektu a postupujte takto:

    1. Aktualizujte všechny výskyty verze 4.0.0.0 "System.Web.Mvc" na 5.0.0.0.0.

    2. Aktualizujte všechny výskyty verze 2.0.0.0 "System.Web.Helpers", "System.Web.WebPages" a "System.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 projektu ASP.NET MVC 4 a webového rozhraní API na ASP.NET MVC 5 a Webové rozhraní API 2.

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

    Tento problém se běžně vyskytuje s vygenerovaným kódem pro model s celočíselnou vlastností v zobrazeních Create and Edit.

    Chcete-li tento problém vyřešit, 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čný vztah důvěryhodnosti. 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.

    Všimněte si, že jako vedlejší účinek nelze použít 4.0 a 5.0 sestavení ve stejné aplikaci. Všechny je potřeba aktualizovat na verzi 5.0.

Šablona SPA s ověřováním na Facebooku může způsobit nestabilitu v IE, zatímco web je hostovaný v intranetové zóně

Šablona SPA poskytuje externí přihlášení k Facebooku. Když je projekt vytvořený pomocí šablony spuštěný místně, může přihlášení 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ž je IE.

Generování uživatelského rozhraní webových formulářů

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

Pokud chcete do projektu webových formulářů přidat MVC, přidejte novou vygenerovanou položku a vyberte závislosti MVC 5. V závislosti na tom, jestli potřebujete všechny soubory obsahu, jako jsou skripty, vyberte buď Minimální, nebo Úplné. Potom přidejte vygenerovanou položku pro MVC, která v 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é provedené změny se vygenerují zpět, ale jiné změny, jako jsou nainstalované balíčky NuGet, se zpět nevrá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 pro MVC opravit, přidejte novou vygenerovanou položku a vyberte závislosti MVC 5 (buď minimální, nebo úplné). Tento proces přidá všechny požadované změny do projektu.

  • Oprava této chyby pro webové 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. Nakonfigurujte WebApiConfig.Register v metodě Application_Start v Global.asax 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