Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Scott Addie
In diesem Artikel führen wir Sie durch die Aktualisierung eines vorhandenen ASP.NET Core 1.x-Projekts auf ASP.NET Core 2.0. Durch die Migration Ihrer Anwendung zu ASP.NET Core 2.0 können Sie viele neue Features und Leistungsverbesserungen nutzen.
Vorhandene ASP.NET Core 1.x-Anwendungen basieren auf versionsspezifischen Projektvorlagen. Da sich das ASP.NET Core-Framework weiterentwickelt, entwickeln sich auch die Projektvorlagen und der darin enthaltene Startcode weiter. Zusätzlich zum Aktualisieren des ASP.NET Core-Frameworks müssen Sie den Code für Ihre Anwendung aktualisieren.
Voraussetzungen
Weitere Informationen finden Sie unter "Erste Schritte mit ASP.NET Core".
Aktualisieren des Zielframeworkmonikers (Target Framework Moniker, TFM)
Projekte für .NET Core sollten die TFM einer Version verwenden, die größer oder gleich .NET Core 2.0 ist. Suchen Sie nach dem <TargetFramework>
Knoten in der .csproj
Datei, und ersetzen Sie den inneren Text durch netcoreapp2.0
:
<TargetFramework>netcoreapp2.0</TargetFramework>
Projekte für .NET Framework sollten die TFM einer Version verwenden, die größer oder gleich .NET Framework 4.6.1 ist. Suchen Sie nach dem <TargetFramework>
Knoten in der .csproj
Datei, und ersetzen Sie den inneren Text durch net461
:
<TargetFramework>net461</TargetFramework>
Hinweis
.NET Core 2.0 bietet eine wesentlich größere Fläche als .NET Core 1.x. Wenn Sie .NET Framework ausschließlich deshalb verwenden, weil APIs in .NET Core 1.x fehlen, könnte die Ausrichtung auf .NET Core 2.0 funktionieren.
Wenn die Projektdatei enthält <RuntimeFrameworkVersion>1.{sub-version}</RuntimeFrameworkVersion>
, lesen Sie dieses GitHub-Problem.
Aktualisieren der .NET Core SDK-Version in „global.json“
Wenn Ihre Lösung von einer global.json Datei abhängt, die auf eine bestimmte .NET Core SDK-Version abzielt, aktualisieren Sie deren version
Eigenschaft zum Verwenden der auf Ihrem Computer installierten Version 2.0:
{
"sdk": {
"version": "2.0.0"
}
}
Aktualisieren von Paketverweisen
Die .csproj
Datei in einem 1.x-Projekt listet jedes NuGet-Paket auf, das vom Projekt verwendet wird.
In einem ASP.NET Core 2.0-Projekt für .NET Core 2.0 ersetzt ein einzelner Metapackageverweis in der .csproj
Datei die Sammlung von Paketen:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.9" />
</ItemGroup>
Alle Features von ASP.NET Core 2.0 und Entity Framework Core 2.0 sind im Metapaket enthalten.
ASP.NET Core 2.0-Projekte für .NET Framework sollten weiterhin auf einzelne NuGet-Pakete verweisen. Aktualisieren Sie das Version
Attribut jedes <PackageReference />
Knotens auf 2.0.0.
Hier ist beispielsweise die Liste der <PackageReference />
Knoten, die in einem typischen ASP.NET Core 2.0-Projekt für .NET Framework verwendet werden:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.0" PrivateAssets="All" />
</ItemGroup>
Das Paket Microsoft.Extensions.CommandLineUtils
wurde zurückgezogen. Es ist weiterhin verfügbar, aber nicht unterstützt.
Aktualisieren von .NET CLI-Tools
Aktualisieren Sie in der .csproj
Datei das Version
Attribut jedes <DotNetCliToolReference />
Knotens auf 2.0.0.
Hier ist beispielsweise die Liste der CLI-Tools, die in einem typischen ASP.NET Core 2.0-Projekt für .NET Core 2.0 verwendet werden:
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" />
<DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="2.0.0" />
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
Package Target Fallback-Eigenschaft umbenennen
Die .csproj
Datei eines 1.x-Projekts hat einen Knoten und eine PackageTargetFallback
Variable verwendet:
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
Benennen Sie sowohl den Knoten als auch die Variable in AssetTargetFallback
um.
<AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wp8+wpa81;</AssetTargetFallback>
Update Main-Methode in Program.cs
In 1.x-Projekten sah die Main
Methode von Program.cs
so aus:
using System.IO;
using Microsoft.AspNetCore.Hosting;
namespace AspNetCoreDotNetCore1App
{
public class Program
{
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
host.Run();
}
}
}
In 2.0 Projekten wurde die Main
Methode Program.cs
vereinfacht:
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
namespace AspNetCoreDotNetCore2App
{
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
}
}
Die Einführung dieses neuen 2.0-Musters wird dringend empfohlen und ist erforderlich, damit Produktfeatures wie Entity Framework (EF) Core Migrationen funktionieren. Beispielsweise führt das Ausführen von Update-Database
über das Paket-Manager-Konsolenfenster oder von dotnet ef database update
über die Befehlszeile (bei Projekten, die in ASP.NET Core 2.0 konvertiert wurden) zu folgendem Fehler:
Unable to create an object of type '<Context>'. Add an implementation of 'IDesignTimeDbContextFactory<Context>' to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.
Hinzufügen von Konfigurationsanbietern
In 1.x-Projekten wurde das Hinzufügen von Konfigurationsanbietern zu einer App über den Startup
Konstruktor durchgeführt. Die Schritte umfassen das Erstellen einer Instanz von ConfigurationBuilder
, das Laden anwendbarer Anbieter (Umgebungsvariablen, App-Einstellungen usw.) und das Initialisieren eines Mitglieds von IConfigurationRoot
.
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
if (env.IsDevelopment())
{
builder.AddUserSecrets<Startup>();
}
builder.AddEnvironmentVariables();
Configuration = builder.Build();
}
public IConfigurationRoot Configuration { get; }
Im vorherigen Beispiel wird das Configuration
-Element sowohl mit Konfigurationseinstellungen von appsettings.json
als auch mit jeder appsettings.{Environment}.json
-Datei geladen, die der IHostingEnvironment.EnvironmentName
-Eigenschaft entspricht. Der Speicherort dieser Dateien befindet sich im selben Pfad wie Startup.cs
.
In 2.0-Projekten wird der 1.x-Projektbausteinkonfigurationscode hinter den Kulissen ausgeführt. Umgebungsvariablen und App-Einstellungen werden beispielsweise beim Start geladen. Der entsprechende Startup.cs
Code wird durch die Initialisierung mit der eingefügten Instanz auf IConfiguration
reduziert.
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
Rufen Sie zum Entfernen der Standardanbieter, die von WebHostBuilder.CreateDefaultBuilder
hinzugefügt wurden, die Clear
-Methode auf der IConfigurationBuilder.Sources
-Eigenschaft innerhalb von ConfigureAppConfiguration
auf. Um Anbieter wieder hinzuzufügen, verwenden Sie die ConfigureAppConfiguration
Methode in Program.cs
:
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureAppConfiguration((hostContext, config) =>
{
// delete all default configuration providers
config.Sources.Clear();
config.AddJsonFile("myconfig.json", optional: true);
})
.Build();
Die konfiguration, die von der CreateDefaultBuilder
Methode im vorherigen Codeausschnitt verwendet wird, ist hier zu sehen.
Weitere Informationen finden Sie unter Konfiguration in ASP.NET Core.
Verschieben des Datenbankinitialisierungscodes
In 1.x-Projekten mit EF Core 1.x wird ein Befehl wie dotnet ef migrations add
folgt ausgeführt:
- Instanziiert eine
Startup
Instanz - Ruft die
ConfigureServices
Methode auf, um alle Dienste mit Abhängigkeitseinfügung (einschließlichDbContext
Typen) zu registrieren. - Führt die erforderlichen Aufgaben aus
In 2.0-Projekten, die EF Core 2.0 verwenden, wird Program.BuildWebHost
aufgerufen, um die Anwendungsdienste zu erhalten. Im Gegensatz zu 1.x hat dies die zusätzliche Nebenwirkung des Aufrufens Startup.Configure
. Wenn Ihre 1.x-App den Datenbankinitialisierungscode in der Configure
Methode aufgerufen hat, können unerwartete Probleme auftreten. Wenn die Datenbank beispielsweise noch nicht vorhanden ist, wird der Seedingcode vor der Ausführung des EF Core Migrationsbefehls ausgeführt. Dieses Problem führt dazu, dass ein dotnet ef migrations list
Befehl fehlschlägt, wenn die Datenbank noch nicht vorhanden ist.
Berücksichtigen Sie den folgenden Initialisierungs-Code für Seed 1.x in der Methode Configure
von Startup.cs
:
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
SeedData.Initialize(app.ApplicationServices);
Verschieben Sie in 2.0 Projekten den SeedData.Initialize
Aufruf an die Main
Methode von Program.cs
:
var host = BuildWebHost(args);
using (var scope = host.Services.CreateScope())
{
var services = scope.ServiceProvider;
try
{
// Requires using RazorPagesMovie.Models;
SeedData.Initialize(services);
}
catch (Exception ex)
{
var logger = services.GetRequiredService<ILogger<Program>>();
logger.LogError(ex, "An error occurred seeding the DB.");
}
}
host.Run();
Ab 2.0 ist es schlechte Praxis, in BuildWebHost
etwas anderes zu tun, außer den Webhost zu erstellen und zu konfigurieren. Alles, was die Ausführung der Anwendung betrifft, sollte außerhalb von BuildWebHost
behandelt werden – in der Regel in der Main
-Methode von Program.cs
.
Überprüfen Sie die Razor Ansichtskompilierungseinstellung
Schnellere Anwendungsstartzeit und kleinere veröffentlichte Bundles sind für Sie von größter Bedeutung. Aus diesen Gründen Razor ist die Ansichtskompilierung in ASP.NET Core 2.0 standardmäßig aktiviert.
Das Festlegen der MvcRazorCompileOnPublish
Eigenschaft auf "true" ist nicht mehr erforderlich. Sofern Sie die Ansichtskompilierung nicht deaktivieren, wird die Eigenschaft möglicherweise aus der .csproj
Datei entfernt.
Bei der Verwendung des .NET Framework als Zielplattform müssen Sie weiterhin explizit das NuGet-Paket Razor in Ihrer Datei referenzieren.
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
Verlassen Sie sich auf Die "Light-up"-Features von Application Insights
Die mühelose Einrichtung der Anwendungsleistungsinstrumentation ist wichtig. Sie können sich jetzt auf die neuen "Light-up"-Features von Application Insights verlassen, die im Visual Studio 2017-Tool verfügbar sind.
ASP.NET Core 1.1-Projekte, die in Visual Studio 2017 erstellt wurden, enthalten standardmäßig Application Insights. Wenn Sie das Application Insights SDK nicht direkt verwenden, außerhalb von Program.cs
und Startup.cs
, führen Sie die folgenden Schritte aus:
Wenn Sie .NET Core verwenden, entfernen Sie den folgenden
<PackageReference />
Knoten aus der.csproj
Datei:<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
Wenn sie auf .NET Core ausgerichtet sind, entfernen Sie den Aufruf der
UseApplicationInsights
Erweiterungsmethode vonProgram.cs
:public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup<Startup>() .UseApplicationInsights() .Build(); host.Run(); }
Entfernen Sie den clientseitigen Application Insights-API-Aufruf von
_Layout.cshtml
. Sie umfasst die folgenden beiden Codezeilen:@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet @Html.Raw(JavaScriptSnippet.FullScript)
Wenn Sie das Application Insights SDK direkt verwenden, fahren Sie damit fort. Das Metapaket 2.0 enthält die neueste Version von Application Insights, sodass ein Paketdowngradefehler angezeigt wird, wenn Sie auf eine ältere Version verweisen.
Authentifizierungs/Identity Verbesserungen übernehmen
ASP.NET Core 2.0 verfügt über ein neues Authentifizierungsmodell und eine Reihe erheblicher Änderungen an ASP.NET Core Identity. Wenn Sie Ihr Projekt mit aktivierten einzelnen Benutzerkonten erstellt haben oder die Authentifizierung manuell hinzugefügt haben, siehe Identity.
Weitere Ressourcen
ASP.NET Core