---

Settembre 2017

Volume 32 Numero 9

Il presente articolo è stato tradotto automaticamente.

ASP.NET Core - Introduzione ad ASP.NET Core 2.0

Da Mike Rousos | 2017 settembre

ASP.NET Core semplifica la creazione di applicazioni Web veloce, portatile e multipiattaforma. In questo articolo illustra lo sviluppo di un semplice sito Web di ASP.NET Core e visualizzerà il ruolo di ogni file viene riprodotto il progetto. Inoltre verrà descritti i concetti importanti di ASP.NET Core lungo il percorso. Esisterà una particolare attenzione alle modifiche apportate in ASP.NET 2.0 Core per consentire ai lettori familiari con ASP.NET Core 1.0 e 1.1 eseguire la transizione a 2.0.

Creazione di un progetto ASP.NET Core

Progetti ASP.NET Core possono essere creati da modelli utilizzando Visual Studio o l'interfaccia della riga di comando di .NET Core (.NET CLI). 2017 di Visual Studio offre un'ottima esperienza di sviluppo .NET Core, con il debug eccezionali, integrazione di Docker e molte altre funzionalità, ma si utilizzerà l'interfaccia CLI di .NET e Visual Studio Code in questa procedura dettagliata, nel caso in cui alcuni si desidera seguire la procedura in un dev Mac o Linux macchina.

Il nuovo comando dotnet viene utilizzato per creare nuovi progetti .NET Core. In esecuzione dotnet nuovo senza argomenti aggiuntivi verranno elencati i modelli di progetto disponibili, come illustrato nella figura 1. Se si ha familiarità con le versioni precedenti di .NET CLI, si noterà un numero di nuovi modelli disponibili nella versione 2.0.

Figura 1 nuovi .NET Core modelli di progetto

Angolare e React.js SPA modelli: Questi modelli creano un'applicazione ASP.NET di base che funge da un'applicazione a pagina singola (usando 4 angolare o React.js) il front-end. I modelli includono sia le applicazioni front-end e back-end, nonché una configurazione Webpack per compilare il front-end e csproj modifiche ad avviare il Webpack compilare ogni volta che viene compilato il progetto ASP.NET Core.

App Web di ASP.NET Core con pagine Razor: Pagine Razor è una nuova funzionalità di ASP.NET 2.0 di base che consente di creare pagine che è possano gestire le richieste direttamente (senza la necessità di un controller). Si tratta di un'opzione utilissima per gli scenari di base di un modello di programmazione basato su pagina.

Per questa procedura dettagliata, iniziamo con il nuovo modello di pagine Razor eseguendo dotnet nuovo razor. Non appena è stato creato il progetto, sarà possibile eseguirla eseguendo dotnet eseguire. Nelle versioni precedenti di .NET Core, sarebbe sono state necessario per eseguire un'operazione restore dotnet prima di installare i pacchetti NuGet necessari. Tuttavia, a partire dalla versione 2.0 di .NET Core, il comando di ripristino, viene ora eseguito automaticamente dai comandi CLI che dipendono da esso. Vado avanti e testare il sito Web di modello Timeout esecuzione dotnet e passando l'URL in cui è in ascolto l'app (probabilmente indirizzo http://localhost:5000/). Verrà visualizzata l'app Web eseguito il rendering (come in figura 2).

Esecuzione di App semplice ASP.NET Core figura 2

È stata completata avviando la prima app di base di ASP.NET 2.0. Dopo aver creato una semplice applicazione Web in esecuzione, diamo un'occhiata al contenuto del progetto per ottenere una migliore comprensione del funzionamento di ASP.NET Core.

Le dipendenze, le origini e le risorse

Il primo file da esaminare è il file di progetto, ovvero il file con estensione csproj. Questo file indica a MSBuild di compilare il progetto, ovvero pacchetti da cui dipende, la versione di .NET Core su target e così via. Se è stato esaminato in precedenza i file con estensione csproj, si noterà che il file di progetto è molto più piccolo. Un notevole sforzo rientra in rendere i file con estensione csproj più brevi e più leggibile. Una modifica significativa che ha contribuito con la compattazione del file di progetto è che l'origine file non è più necessario da elencare in modo esplicito. Al contrario, il SDK di .NET Core compilerà automaticamente qualsiasi file con estensione cs accanto al file di progetto o in tutte le directory nella directory del file con estensione csproj. Analogamente, qualsiasi file con estensione resx trovato verranno incorporati come risorse. Se si preferisce non disporre di tutti i file con estensione cs compilati, è possibile rimuovere l'elemento ItemGroup compilare o disabilitare gli elementi di compilazione predefinito interamente impostando la proprietà EnableDefaultCompileItems su false.

La versione di .NET che deve eseguire l'app è specificata dall'elemento < TargetFramework >. È impostato su netcoreapp2.0 per sfruttare le nuove funzionalità di ASP.NET 2.0 Core e la quantità più grande 2.0 di .NET Core della superficie di attacco.

L'elemento < PackageReference > al centro il file con estensione csproj indica un pacchetto NuGet da cui dipende il progetto. Si noterà che in ASP.NET 2.0 Core includono ora una sola meta - pacchetto per impostazione predefinita (Microsoft.AspNetCore.All). Questo pacchetto include tutti gli altri pacchetti Microsoft.AspNetCore un riferimento conciso e rende i file di progetto ASP.NET Core 2.0 molto inferiori rispetto a file di progetto da versioni precedenti. Dipendenze di NuGet aggiuntive possono essere aggiunti mediante l'aggiunta di più elementi < PackageReference >, utilizzando l'interfaccia utente di gestione di pacchetto NuGet di Visual Studio o con il dotnet CLI .NET aggiungere il comando.

Se si utilizza un modello SPA (angolare, react o reactredux), potrebbe anche esistere destinazioni personalizzate definite nel file con estensione csproj per assicurarsi che Webpack è stato eseguito durante la compilazione del progetto.

Creazione ed esecuzione di Host Web

Program.cs rappresenta il punto di ingresso dell'applicazione. Le applicazioni ASP.NET Core sono applicazioni console, così come tutte le applicazioni console hanno un metodo Main che inizia quando viene eseguita l'app.

Il contenuto dei metodi Main dei modelli componenti di base di ASP.NET 2.0 è piuttosto semplice, creano un oggetto IWebHost e chiamare l'esecuzione su di esso.

Se ASP.NET Core 1.0 è stato utilizzato in precedenza, si noterà che questo file è un po' più semplice che il file program.cs da questi modelli precedenti. Il motivo per questo è il nuovo metodo WebHost.CreateDefaultBuilder. Metodo Main dell'applicazione ASP.NET Core in precedenza, consentono di configurare un WebHostBuilder per creare l'istanza IWebHost. Questa configurazione inclusa i passaggi, ad esempio si specifica un server Web, impostare il percorso radice del contenuto e attivazione dell'integrazione di IIS.

Il nuovo metodo CreateDefaultBuilder semplifica operazioni creando un IWebHost ready to go con la configurazione più comune è già. Oltre a specificare gli elementi elencati in precedenza, CreateDefaultBuilder anche si occupa di un programma di installazione che in precedenza è stata gestita in Startup.cs (impostazione delle informazioni di configurazione e registrazione dei provider di registrazione predefinito). Poiché ASP.NET Core è open source, è possibile visualizzare tutti i dettagli dell'attività visualizzando la relativa origine in GitHub CreateDefaultBuilder (bit.ly/2uR1Dar) se si è interessati.

Prendiamo brevemente un aspetto più importante chiamate effettuate in CreateDefaultBuilder e il loro scopo. Anche se queste vengono tutte eseguite (da CreateDefaultBuilder), è comunque sufficiente comprendere ciò che accade dietro le quinte.

UseKestrel specifica che l'applicazione deve utilizzare Kestrel, un server Web di e multipiattaforma basate su libuv. L'altra opzione qui sarebbe utilizzare HttpSys come server Web (UseHttpSys). HttpSys è supportato solo in Windows (Windows 7/2008 R2 e versioni successive), ma ha il vantaggio di consentire l'autenticazione di Windows ed è sicuro per l'esecuzione esposte direttamente a Internet (Kestrel, d'altra parte, devono si trovano dietro un proxy inverso, come IIS, Nginx o Apache Se le richieste, riceverà da Internet).

UseContentRoot specifica la directory radice per l'applicazione in cui ASP.NET Core disponibili a livello di sito contenuto come file di configurazione. Si noti che questo non è lo stesso come radice Web (in cui i file statici saranno serviti da), anche se per impostazione predefinita, Web radice è basata sulla radice del contenuto ([ContentRoot] / wwwroot).

ConfigureAppConfiguration crea l'oggetto di configurazione che nell'applicazione verrà utilizzato per leggere le impostazioni in fase di esecuzione. Quando viene chiamato da CreateDefaultBuilder, questo verrà letta le impostazioni di configurazione dell'applicazione da un file appSettings. JSON, un file con estensione JSON specifici dell'ambiente (se presente), le variabili di ambiente e gli argomenti della riga di comando. Se in un ambiente di sviluppo, useranno anche informazioni riservate dell'utente. Questo metodo è stato introdotto in ASP.NET 2.0 Core e vedremo, in modo più dettagliato più avanti.

ConfigureLogging imposta il livello di registrazione per l'applicazione. Quando viene chiamato da CreateDefaultBuilder, vengono aggiunti console e provider di registrazione di debug. Ad esempio ConfigureAppConfiguration, questo metodo è nuovo e viene illustrato più avanti.

UseIISIntegration configura l'applicazione per l'esecuzione in IIS. Si noti che UseKestrel è ancora necessario. IIS funge da proxy inverso e Kestrel viene ancora utilizzato come host. Inoltre, UseIISIntegration non ha alcun effetto se l'app non è in esecuzione dietro IIS, pertanto è opportuno chiamare anche se in scenari di IIS non verrà eseguita l'app.

In molti casi, la configurazione predefinita fornita da CreateDefaultBuilder saranno sufficiente. Oltre a tutto ciò che è necessario che chiamata consiste nello specificare la classe di avvio per l'applicazione con una chiamata a UseStartup < T >, dove T è il tipo di avvio.

Se CreateDefaultBuilder non soddisfa le esigenze dello scenario, è possibile personalizzare la modalità di creazione di IWebHost. Se è necessario apportare solo modifiche di piccole entità, è possibile chiamare CreateDefaultBuilder e quindi modificare WebHostBuilder restituito (ad esempio chiamando ConfigureAppConfiguration nuovamente, ad esempio, per aggiungere altre origini di configurazione). Se è necessario apportare modifiche più grande per il IWebHost, è possibile ignorare completamente CreateDefaultBuilder chiamante e appena costruire un WebHostBuilder manualmente, come con ASP.NET Core 1.0 o 1.1. Anche se si effettua questa scelta, è possibile comunque sfruttare i nuovi metodi ConfigureAppConfiguration e ConfigureLogging. Altre informazioni sulla configurazione dell'host Web sono disponibili in bit.ly/2uuSwwM.

Ambienti di ASP.NET Core

Un paio di azioni accetta CreateDefaultBuilder dipendono in ambiente di cui l'applicazione è in esecuzione di ASP.NET Core. Il concetto di ambienti non è nuovo in 2.0, ma è opportuno esaminare brevemente perché viene visualizzato di frequente.

In ASP.NET Core, l'ambiente di che esecuzione in un'applicazione è indicata dalla variabile di ambiente ASPNETCORE_ENVIRONMENT. È possibile impostarlo su qualsiasi valore desiderato, ma i valori di sviluppo, gestione temporanea e produzione sono in genere utilizzato. In tal caso, se si imposta la variabile ASPNETCORE_ENVIRONMENT per lo sviluppo di prima di chiamare dotnet eseguire (o se si imposta tale variabile di ambiente in un file di launchSettings.json), l'app viene eseguita in modalità di sviluppo (invece di produzione, ovvero l'impostazione predefinita senza le variabili impostate). Questo valore viene utilizzato da diverse funzionalità di ASP.NET Core (sarà farvi riferimento quando si parla di configurazione e la registrazione in un secondo momento) per modificare il comportamento di runtime e sono accessibili nel codice utilizzando il servizio IHostingEnvironment. Ulteriori informazioni sugli ambienti di ASP.NET Core sono disponibile in documenti ASP.NET Core (bit.ly/2eICDMF).

Configurazione di ASP.NET Core

Interfaccia IConfiguration del pacchetto Microsoft.Extensions.Configuration ASP.NET utilizzata per fornire le impostazioni di configurazione di runtime. Come accennato in precedenza, CreateDefaultBuilder consente di leggere le impostazioni di variabili di ambiente e i file con estensione JSON. Il sistema di configurazione è estensibile, tuttavia e può leggere le informazioni di configurazione da una vasta gamma di provider (file con estensione JSON, file con estensione XML, file con estensione ini, le variabili di ambiente, insieme di credenziali chiave di Azure e così via.).

Quando si utilizzano oggetti IConfiguration e IConfigurationBuilder, tenere presente che l'ordine in cui che i provider vengono aggiunti è importante. Provider successive possono eseguire l'override di impostazioni dal provider precedenti, pertanto è opportuno aggiungere provider di base comuni prima, quindi, in un secondo momento, i provider specifico dell'ambiente che potrebbero eseguire l'override di alcune delle impostazioni.

Le impostazioni di configurazione di ASP.NET Core sono gerarchiche. Nel nuovo progetto creato, ad esempio, appSettings. JSON (vedere figura 3) contiene un elemento di registrazione principale con impostazioni secondari disponibili al suo interno. Queste impostazioni indicano la priorità minima di messaggi da registrare (mediante le impostazioni di "LogLevel") e se l'ambito di logica dell'applicazione in fase di che registrazione del messaggio deve essere registrato (tramite IncludeScopes). Per recuperare le impostazioni annidate come queste, è possibile utilizzare il metodo IConfiguration.GetSection per recuperare una singola sezione della configurazione o specificare il percorso completo di una particolare impostazione, delimitata da virgola. In tal caso, è Impossibile recuperare il valore di IncludeScopes nel progetto come:

Figura 3 File delle impostazioni ASP.NET Core

{
  "Logging": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Warning"
      }
    },
    "Console": {
      "LogLevel": {
        "Default": "Warning"
      }
    }
  }
}

Configurazione ["registrazione: IncludeScopes"]

Quando si definiscono le impostazioni di configurazione con le variabili di ambiente, il nome di variabile di ambiente deve includere tutti i livelli della gerarchia e può essere delimitato con due punti (:) oppure un doppio carattere di sottolineatura (_). Ad esempio, una variabile di ambiente denominata Logging__IncludeScopes necessario sostituire l'impostazione IncludeScopes del file di esempio in figura 3, presupponendo che il provider di variabili di ambiente viene aggiunto dopo il file di impostazioni, ad esempio nel caso CreateDefaultBuilder è.

Poiché WebHost.CreateDefaultBuilder sta leggendo configurazione appSettings. JSON sia i file con estensione JSON specifici dell'ambiente, si noterà che il comportamento di registrazione cambia quando si modificano gli ambienti (appsettings. Development.JSON sostituiscono le impostazioni di LogLevel dell'appSettings. JSON predefinito con livelli di "debug" e "informazioni" più dettagliati). Se si imposta l'ambiente di sviluppo prima di chiamare dotnet eseguire, si noterà un po' di registrazione in corso nella console (che è molto utile perché è utile per il debug). D'altra parte, se si imposta l'ambiente di produzione, si otterranno qualsiasi registrazione nella console ad eccezione di errori e avvisi (che è inoltre ideale perché registrazione nella console è lenta e deve essere mantenuta al minimo in produzione).

Se si ha esperienza con ASP.NET Core 1.0 e 1.1, è possibile notare che il metodo ConfigureAppConfiguration è una novità di 2.0. In precedenza, era comune per creare un IConfiguration come parte della creazione del tipo di avvio. Utilizzando il nuovo metodo ConfigureAppConfiguration è un'alternativa utile perché aggiorna l'oggetto IConfiguration archiviato nel contenitore di injection (DI) dipendenza dell'applicazione per semplificarne il recupero futuro e rende disponibili anche le impostazioni di configurazione in precedenza nel ciclo di vita dell'applicazione.

Registrazione di ASP.NET Core

Come con l'installazione di configurazione, se si ha familiarità con le versioni precedenti di ASP.NET Core si ricorderà registrazione programma di installazione viene eseguita in Startup.cs anziché in Program.cs. In ASP.NET 2.0 Core registrazione programma di installazione può ora essere eseguita quando si compila un IWebHost tramite il metodo ConfigureLogging.

È comunque possibile configurare la registrazione in avvio (tramite servizi. Add-Logging in Startup.ConfigureServices), ma tramite la configurazione di registrazione in fase di creazione di host Web, il tipo di avvio è semplice e la registrazione è disponibile anche in precedenza nel processo di avvio dell'app.

Ad esempio di configurazione, anche la registrazione di ASP.NET Core è estensibile. Provider diversi sono registrati per l'accesso a endpoint diversi. Molti provider sono disponibili immediatamente con un riferimento a Microsoft.AspNetCore.All e anche informazioni sono disponibili dalla community degli sviluppatori .NET.

Come si può notare nel codice sorgente del WebHost.CreateDefaultBuilder, aggiungere provider di log tramite una chiamata di metodi di estensione specifico del provider come AddDebug o AddConsole sul ILoggingBuilder. Se si utilizza WebHost.CreateDefaultBuilder ma si vuole comunque registrare i provider di registrazione diverso da una Console quelli e di Debug predefinito, è possibile farlo con una chiamata aggiuntiva al ConfigureLogging sul IWebHostBuilder restituito da CreateDefaultBuilder

Dopo la registrazione è stata configurata e i provider registrati, ASP.NET Core registrerà automaticamente i messaggi relativi al proprio lavoro per elaborare le richieste in ingresso. È anche possibile registrare i messaggi di diagnostica richiedendo un oggetto ILogger tramite l'inserimento di dipendenze (ulteriori informazioni su questo nella sezione successiva). Le chiamate a ILogger.Log e varianti specifiche di livello (ad esempio LogCritical, LogInformation e così via) vengono utilizzate per registrare i messaggi.

Il tipo di avvio

Ora che è stato esaminato Program.cs per vedere come viene creato l'host Web, di seguito consente di passare al Startup.cs. Il tipo di avvio che deve usare l'app è indicato dalla chiamata a UseStartup durante la creazione di IWebHost. Non molto ha modificato in Startup.cs in ASP.NET 2.0 Core (tranne che diventino più semplice perché la registrazione e configurazione vengono impostati in Program.cs), ma verranno esaminate brevemente due metodi importanti del tipo di avvio perché si centralità per un'applicazione ASP.NET Core.

Metodo ConfigureServices del tipo di attacco intrusivo nel codice di avvio dipendenza aggiunge servizi al contenitore dell'inserimento di dipendenze dell'applicazione. Tutte le app ASP.NET Core dispongono di un contenitore di inserimento di dipendenza predefinito per archiviare i servizi per un uso successivo. Questo consente ai servizi di essere reso disponibile senza l'accoppiamento stretto ai componenti che dipendono da essi. Abbiamo già visto alcuni esempi di questo tipo, ovvero ConfigureAppConfiguration sia ConfigureLogging aggiungerà servizi per il contenitore per l'utilizzo in un secondo momento nell'applicazione. In fase di esecuzione, se un'istanza di un tipo viene chiamata, ASP.NET Core recupererà automaticamente l'oggetto dal contenitore dell'inserimento di dipendenza se possibile.

Ad esempio, la classe di avvio del progetto ASP.NET Core 2.0 ha un costruttore che accetta un parametro IConfiguration. Questo costruttore verrà chiamato automaticamente quando il IWebHost inizia a eseguire. In questo caso, ASP.NET Core fornirà l'argomento obbligatorio IConfiguration dal contenitore di inserimento di dipendenza.

Ad esempio, se si desidera registrare i messaggi da una pagina Razor, è possibile richiedere un oggetto logger come parametro al costruttore del modello di pagina (ad esempio, la modalità avvio richiede un oggetto IConfiguration) o in cshtml con il @ inserire la sintassi, come illustrato nel seguente:

@using Microsoft.Extensions.Logging
@inject ILogger<Index_Page> logger

@functions {
  public void OnGet()
    {
      logger.LogInformation("Beginning GET");
    }
}

Potrebbe verificarsi un comportamento simile per recuperare un oggetto IConfiguration o qualsiasi altro tipo che è stato registrato come servizio. In questo modo, il tipo di avvio, pagine Razor, controller e così via, può regime di controllo libero dipendono dai servizi forniti con il contenitore dell'inserimento di dipendenza.

Come indicato all'inizio di questa sezione, i servizi vengono aggiunti per il contenitore dell'inserimento di dipendenza nel metodo Startup.ConfigureServices. Il modello di progetto utilizzato per creare l'applicazione è già dispone di una chiamata in ConfigureServices: servizi. AddMvc. Come può immaginare, questo registra i servizi necessari per il framework di MVC.

Un altro tipo di servizio che è frequente vedere registrati nel metodo ConfigureServices è Entity Framework Core. Anche se non viene utilizzato in questo esempio, le applicazioni che utilizzano in genere di Entity Framework Core registrare il DbContexts necessari per l'utilizzo di modelli di Entity Framework utilizzando chiamate ai servizi. AddDbContext.

È anche possibile registrare tuoi tipi e i servizi qui chiamando servizi. AddTransient, i servizi. AddScoped o servizi. AddSingleton (a seconda della durata necessaria per gli oggetti di dipendenza fornita injection). La registrazione come singleton comporterà una singola istanza del servizio che viene restituito ogni volta che viene richiesto il tipo, mentre la registrazione come temporaneo genererà una nuova istanza da creare per ogni richiesta. Aggiunta di un ambito causerà una singola istanza di un servizio per essere utilizzati in tutta l'elaborazione di una singola richiesta HTTP. Ulteriori informazioni sull'inserimento di dipendenze in ASP.NET Core sono disponibili in bit.ly/2w7XtJI.

Pipeline di elaborazione delle richieste HTTP e Middleware l'altro metodo nel tipo di avvio importante è il metodo di configurazione. Questa opzione è quando il nucleo dell'applicazione ASP.NET di base, la pipeline di elaborazione delle richieste HTTP, è impostato. In questo metodo, diverse parti di middleware vengono registrati che verrà agiscono su HTTP in ingresso le richieste per generare le risposte.

In Startup.Configure, i componenti middleware vengono aggiunti a un IApplicationBuilder per formare una pipeline di elaborazione. Quando arriva una richiesta, verrà richiamata nella prima parte di middleware registrato. Il middleware eseguirà la logica deve quindi chiamare la parte successiva middleware nella pipeline o, se è completamente gestito la risposta, tornare nella parte precedente di middleware (se non c'è una precedente) in modo da poter eseguire qualsiasi la logica necessaria dopo che è stata preparata una risposta. Questo modello di chiamata di componenti middleware in ordine l'arrivo di una richiesta e quindi in ordine inverso dopo che è stata gestita come illustrata nel figura 4.

Pipeline di elaborazione nella figura 4 ASP.NET Core Middleware

Per eseguire un esempio concreto, figura 5 Mostra il metodo di configurazione dal progetto di modello. Quando arriva una richiesta di nuovo, spostarlo prima di tutto il middleware DeveloperExceptionPage o il middleware ExceptionHandler, a seconda dell'ambiente (come prima, configurato con la variabile di ambiente ASPNETCORE_ENVIRONMENT). Questi componenti middleware non intervenire quantità inizialmente, ma dopo la richiesta è nuovamente fuori dalla pipeline middleware successivo middleware è stata eseguita e verranno controllare e gestire le eccezioni.

Figura 5 ASP.NET Core Startup.Configure metodo imposta la pipeline Middleware

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  if (env.IsDevelopment())
  {
    app.UseDeveloperExceptionPage();
  }
  else
  {
    app.UseExceptionHandler("/Error");
  }

  app.UseStaticFiles();

  app.UseMvc(routes =>
  {
    routes.MapRoute(
      name: "default",
      template: "{controller=Home}/{action=Index}/{id?}");
  });
}

Quindi, StaticFiles verrà chiamato middleware, che possono servire la richiesta, fornendo un file statico (un'immagine o uno stile foglio, ad esempio). In caso affermativo, verrà interrotta la pipeline e restituire il controllo per il middleware precedente (gestori di eccezioni). Se il middleware StaticFiles non può fornire una risposta, chiama la parte successiva middleware, il middleware MVC. Questo middleware tenterà di indirizzare la richiesta a un controller MVC (o una pagina di Razor) di evasione degli ordini, a seconda delle opzioni di routine specificato.

L'ordine in cui che sono registrati i componenti middleware è molto importante. Se è stato UseStaticFiles dopo UseMvc, l'applicazione cercherà di indirizzare tutte le richieste ai controller MVC prima dell'archiviazione per i file statici. Che potrebbe peggiorare comporterà una notevole prestazioni! Se è stato fornito il middleware di gestione delle eccezioni in un secondo momento nella pipeline, non essere in grado di gestire le eccezioni che si verificano nei componenti middleware precedente.

Pagine Razor

Oltre all'estensione. csproj, program.cs e startup.cs file, il progetto ASP.NET Core contiene anche una cartella che contiene le pagine dell'applicazione Razor. Le pagine sono simili alle visualizzazioni MVC, ma le richieste possono essere instradate direttamente a una pagina Razor senza la necessità di un controller separato. Questo rende possibile semplificare le applicazioni basate su pagina e mantenere le visualizzazioni e visualizzare i modelli di insieme. Il modello che supporta la pagina può essere incluso nella pagina cshtml direttamente (in una direttiva @functions) o in un file di codice separato, cui viene fatto riferimento con la direttiva @model.

Per ulteriori informazioni sulle pagine Razor, l'estrazione articolo Steve Smith, "più semplice ASP.NET MVC App con Razor pagine," anche questo problema.

Conclusioni

Probabilmente questa procedura dettagliata spiega come creare una nuova applicazione Web ASP.NET Core 2.0 e spiega il contenuto di nuovi modelli di progetto. È stato rivisto dal file con estensione csproj semplificato, il contenuto del progetto per il punto di ingresso dell'applicazione e la configurazione host Web in Program.cs, con la registrazione del servizio e del middleware in Startup.cs.

Per mantenere approfondire l'argomento potenzialità di ASP.NET Core, potrebbe essere utile creare alcuni nuovi progetti con alcuni altri modelli, ad esempio, il modello API Web o forse alcuni dei nuovi modelli SPA. È anche possibile provare la distribuzione di app ASP.NET Core in Azure come un'applicazione servizio Web App o creandone un pacchetto dell'applicazione in un'immagine Linux o Windows Docker. E, naturalmente, verificare la documentazione completa in docs.microsoft.com/aspnet/core per ulteriori informazioni sugli argomenti trattati in questo articolo e altro ancora.

---

Mike Rousosè un tecnico del software principale del team di .NET cliente esito positivo. Rousos è stato un membro del team di .NET dal 2004, lavorando tecnologie, tra cui sicurezza gestita, analisi, hosting e, più recentemente, .NET Core.

Grazie per i seguenti esperti Microsoft che ha revisionato in questo articolo: Glenn Condron e Ryan Nowak

---

Viene illustrato in questo articolo nel forum di MSDN Magazine