Sündmused
Power BI DataVizi maailmameistrivõistlused
14. veebr, 16 - 31. märts, 16
Nelja võimalusega siseneda, võiksite võita konverentsipaketi ja jõuda LIVE Grand Finale'i las Vegases
LisateaveSeda brauserit enam ei toetata.
Uusimate funktsioonide, turbevärskenduste ja tehnilise toe kasutamiseks võtke kasutusele Microsoft Edge.
By Scott Addie
In this article, we walk you through updating an existing ASP.NET Core 1.x project to ASP.NET Core 2.0. Migrating your application to ASP.NET Core 2.0 enables you to take advantage of many new features and performance improvements.
Existing ASP.NET Core 1.x applications are based off of version-specific project templates. As the ASP.NET Core framework evolves, so do the project templates and the starter code contained within them. In addition to updating the ASP.NET Core framework, you need to update the code for your application.
See Get Started with ASP.NET Core.
Projects targeting .NET Core should use the TFM of a version greater than or equal to .NET Core 2.0. Search for the <TargetFramework>
node in the .csproj
file, and replace its inner text with netcoreapp2.0
:
<TargetFramework>netcoreapp2.0</TargetFramework>
Projects targeting .NET Framework should use the TFM of a version greater than or equal to .NET Framework 4.6.1. Search for the <TargetFramework>
node in the .csproj
file, and replace its inner text with net461
:
<TargetFramework>net461</TargetFramework>
Märkus
.NET Core 2.0 offers a much larger surface area than .NET Core 1.x. If you're targeting .NET Framework solely because of missing APIs in .NET Core 1.x, targeting .NET Core 2.0 is likely to work.
If the project file contains <RuntimeFrameworkVersion>1.{sub-version}</RuntimeFrameworkVersion>
, see this GitHub issue.
If your solution relies upon a global.json file to target a specific .NET Core SDK version, update its version
property to use the 2.0 version installed on your machine:
{
"sdk": {
"version": "2.0.0"
}
}
The .csproj
file in a 1.x project lists each NuGet package used by the project.
In an ASP.NET Core 2.0 project targeting .NET Core 2.0, a single metapackage reference in the .csproj
file replaces the collection of packages:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.9" />
</ItemGroup>
All the features of ASP.NET Core 2.0 and Entity Framework Core 2.0 are included in the metapackage.
ASP.NET Core 2.0 projects targeting .NET Framework should continue to reference individual NuGet packages. Update the Version
attribute of each <PackageReference />
node to 2.0.0.
For example, here's the list of <PackageReference />
nodes used in a typical ASP.NET Core 2.0 project targeting .NET Framework:
<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>
The package Microsoft.Extensions.CommandLineUtils
has been retired. It is still available but unsupported.
In the .csproj
file, update the Version
attribute of each <DotNetCliToolReference />
node to 2.0.0.
For example, here's the list of CLI tools used in a typical ASP.NET Core 2.0 project targeting .NET Core 2.0:
<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>
The .csproj
file of a 1.x project used a PackageTargetFallback
node and variable:
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
Rename both the node and variable to AssetTargetFallback
:
<AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wp8+wpa81;</AssetTargetFallback>
In 1.x projects, the Main
method of Program.cs
looked like this:
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 projects, the Main
method of Program.cs
has been simplified:
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();
}
}
The adoption of this new 2.0 pattern is highly recommended and is required for product features like Entity Framework (EF) Core Migrations to work. For example, running Update-Database
from the Package Manager Console window or dotnet ef database update
from the command line (on projects converted to ASP.NET Core 2.0) generates the following error:
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.
In 1.x projects, adding configuration providers to an app was accomplished via the Startup
constructor. The steps involved creating an instance of ConfigurationBuilder
, loading applicable providers (environment variables, app settings, etc.), and initializing a member of 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; }
The preceding example loads the Configuration
member with configuration settings from appsettings.json
as well as any appsettings.{Environment}.json
file matching the IHostingEnvironment.EnvironmentName
property. The location of these files is at the same path as Startup.cs
.
In 2.0 projects, the boilerplate configuration code inherent to 1.x projects runs behind-the-scenes. For example, environment variables and app settings are loaded at startup. The equivalent Startup.cs
code is reduced to IConfiguration
initialization with the injected instance:
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
To remove the default providers added by WebHostBuilder.CreateDefaultBuilder
, invoke the Clear
method on the IConfigurationBuilder.Sources
property inside of ConfigureAppConfiguration
. To add providers back, utilize the ConfigureAppConfiguration
method 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();
The configuration used by the CreateDefaultBuilder
method in the preceding code snippet can be seen here.
For more information, see Configuration in ASP.NET Core.
In 1.x projects using EF Core 1.x, a command such as dotnet ef migrations add
does the following:
Startup
instanceConfigureServices
method to register all services with dependency injection (including DbContext
types)In 2.0 projects using EF Core 2.0, Program.BuildWebHost
is invoked to obtain the application services. Unlike 1.x, this has the additional side effect of invoking Startup.Configure
. If your 1.x app invoked database initialization code in its Configure
method, unexpected problems can occur. For example, if the database doesn't yet exist, the seeding code runs before the EF Core Migrations command execution. This problem causes a dotnet ef migrations list
command to fail if the database doesn't yet exist.
Consider the following 1.x seed initialization code in the Configure
method of Startup.cs
:
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
SeedData.Initialize(app.ApplicationServices);
In 2.0 projects, move the SeedData.Initialize
call to the Main
method of 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();
As of 2.0, it's bad practice to do anything in BuildWebHost
except build and configure the web host. Anything that's about running the application should be handled outside of BuildWebHost
— typically in the Main
method of Program.cs
.
Faster application startup time and smaller published bundles are of utmost importance to you. For these reasons, Razor view compilation is enabled by default in ASP.NET Core 2.0.
Setting the MvcRazorCompileOnPublish
property to true is no longer required. Unless you're disabling view compilation, the property may be removed from the .csproj
file.
When targeting .NET Framework, you still need to explicitly reference the Microsoft.AspNetCore.Mvc.Razor.ViewCompilation NuGet package in your .csproj
file:
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
Effortless setup of application performance instrumentation is important. You can now rely on the new Application Insights "light-up" features available in the Visual Studio 2017 tooling.
ASP.NET Core 1.1 projects created in Visual Studio 2017 added Application Insights by default. If you're not using the Application Insights SDK directly, outside of Program.cs
and Startup.cs
, follow these steps:
If targeting .NET Core, remove the following <PackageReference />
node from the .csproj
file:
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
If targeting .NET Core, remove the UseApplicationInsights
extension method invocation from Program.cs
:
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
host.Run();
}
Remove the Application Insights client-side API call from _Layout.cshtml
. It comprises the following two lines of code:
@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet
@Html.Raw(JavaScriptSnippet.FullScript)
If you are using the Application Insights SDK directly, continue to do so. The 2.0 metapackage includes the latest version of Application Insights, so a package downgrade error appears if you're referencing an older version.
ASP.NET Core 2.0 has a new authentication model and a number of significant changes to ASP.NET Core Identity. If you created your project with Individual User Accounts enabled, or if you have manually added authentication or Identity, see Migrate Authentication and Identity to ASP.NET Core 2.0.
Toote „ASP.NET Core“ tagasiside
ASP.NET Core on avatud lähtekoodiga projekt. Tagasiside andmiseks valige link:
Sündmused
Power BI DataVizi maailmameistrivõistlused
14. veebr, 16 - 31. märts, 16
Nelja võimalusega siseneda, võiksite võita konverentsipaketi ja jõuda LIVE Grand Finale'i las Vegases
LisateaveKoolitus
Moodul
Secure a .NET web app with the ASP.NET Core Identity framework - Training
Learn how to add authentication and authorization to a .NET web app using the ASP.NET Core Identity framework.
Sertimine
Microsoft Certified: Identity and Access Administrator Associate - Certifications
Demonstrate the features of Microsoft Entra ID to modernize identity solutions, implement hybrid solutions, and implement identity governance.
Dokumentatsioon
Migrate from ASP.NET Core 5.0 to 6.0
Learn how to migrate an ASP.NET Core 5.0 project to ASP.NET Core 6.0.
Migrate from ASP.NET Core 2.0 to 2.1
This article covers the basics of migrating an ASP.NET Core 2.0 app to 2.1.
Migrate from ASP.NET Core 3.1 to 5.0
Learn how to migrate an ASP.NET Core 3.1 project to ASP.NET Core 5.0.