Introduction to ASP. NET Core 1.1 Preview 1 (including. NETCore 1.1 upgrade announcement) and previewcore
ASP. NET Core 1.1 Preview 1 was released on July 1, October 25, 2016. This version includes many great new features and many bug fixes and general enhancements.
To update an existing project to ASP. NET Core 1.1 Preview 1, perform the following operations:
1. download and install the updated. NET Core 1.1 Prevew 1 SDK
2. Update the project to use. NET Core 1.1 Preview 1 as described in. NET Core 1.1 Preview 1.
3. Update your ASP. NET Core package dependencies to use the new version 1.1.0-preview1
Note: To use the NuGet Package Manager in Visual Studio to update the package to 1.1 Preview 1, you need to download and install the NuGet Package Manager for Visual Studio 2015 3.5 RC1 or later.
You should try 1.1 now!
. NET Core 1.1 Preview 1 upgrade announcement
In October 25, 2016,. NET Core 1.1 Preview 1 was released. It includes support for other Linux releases, many updates, and is currently the first version. All these changes are described below. This version is a preview version to view. NET Core 1.1 earlier. It is not "Go Live" and is not recommended for production workloads.
For more information about EntityFramework Core 1.1 Preview 1, refer to my previous blog.
You can download the version immediately ::
- Windows x64
- Windows x86
- MacOS x64
- Linux x64
You can view the complete. NET Core 1.1 download on the. NET Core preview and download page.
. NET Core 1.1 preview 1 Docker images in Docker can also be found in the microsoft/dotnet repository. You can use the dotnetapp-preview example in the. NET Core Docker Samples repository to view the new Docker image.
You can find the current version of .net Core 1.0 on the dot.net/corepage. . NET Core 1.1 is also listed on this page after it is released as a stable version.
. NET Core 1.1 Preview 1 improvement
. NET Core 1.1 is the first minor update of 1.x. Its main product topic is to add support for new operating system distribution.
. NET Core 1.1 Preview 1 operating system distribution
Added support for the following distributions:
- Linux Mint 18
- OpenSUSE 42.1
- MacOS 10.12
- Windows Server 2016
You can view the complete Supported Release in. NET Core 1.1 Preview 1 release notes.
. NET Core 1.1 Preview 1 APIs
1380 APIs are added in this version. You can view the complete set in API differences. NET core application 1.0 (reference) VS. NET core application 1.1 (reference.
Added APIs to enable specific scenarios. No specific topic is added for the API.
. NET Standard 1.6.1-preview1 is released as part of this version. Still supported by. NET standard 2.0.
. NET Core 1.1 Preview 1 fixed
Many specific product changes were made. You can view the complete. NET Core 1.1 preview 1 submission for more information.
The previous MSBuild and CSProj changes are not part of this version, but are still valid.
. NET Core 1.1 Preview 1 parallel installation using. NET Core 1.0
. NET Core 1.1 preview 1 and. NET Core 1.0 are installed in parallel. The. NET Core 1.0 application will continue to use the. NET Core 1.0 runtime. The. NET Core 1.0 environment is designed to have minor or major versions installed later.
Only one command-dotnet new-will change with the installation of. NET Core 1.1. Dotnet new will create a new project that requires. NET Core 1.1 Preview 1, instead of. NET Core 1.0. Therefore, you may want to avoid installing it on a. NET Core 1.0-based development machine using the command line tool. If you are on Windows and use Visual Studio to create a new project instead of dotnet, installing. NET Core 1.1 is a good idea.
Dotnet new will create a new project for the latest installed. NET Core version.
. NET Core 1.1 Preview 1
You can start by installing. NET Core 1.1 Preview. Then, you can use the. NET Core tool just like using. NET Core 1.0. Try the following command set to create, build, and run the. NET Core 1.1 Preview 1 application:
dotnet newdotnet restoredotnet run
You can view the dotnetapp-preview example to try out the. NET Core 1.1 preview 1 application, regardless of whether or not Docker is used.
. NET Core 1.1 Preview 1 upgrade existing projects
You can.. NET Core project.. NET Core 1.0 upgraded. NET Core 1.1 Preview 1. I will show you the new project generated by the dotnet new command. json file. This is the best way to view the new version values that need to be copied/pasted to the existing project. json file. Currently, there are no automated tools to upgrade existing projects to a later version of. NET Core.
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {},
"frameworks": {
"netcoreapp1.1": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0-preview1-001100-00"
}
},
"imports": "dnxcore50"
}
}
}
This project. json file is very similar to. NET Core 1.0 project. json except for netcoreapp1.1 and 1.1.0-preview1-001100-00 target framework and meta package version strings.
You can use the following replace to update the project. json file that you want to temporarily or permanently move to. NET Core 1.1.
- Update the target framework of netcoreapp1.0 to netcoreapp1.1.
- Update the Microsoft. NETCore. App package version from 1.0.x (for example, 1.0.0 or 1.0.1) to 1.1.0-preview1-001100-00.
You can also only write 1.1.0-preview1-* to skip construction-specific information. It works so that you can easily move forward with. NET Core 1.1 builds if you adopt those. When. NET Core 1.1 is released as a stable version, you will change the metadatabase version to 1.1.0. The target framework version does not change the lifecycle of. NET Core 1.1. Upgrade to. NET Core 1.1 Preview 1 Docker Image
. NET Core 1.1 preview 1 the image has been published to the microsoft/dotnet repository. Two new labels for. NET Core 1.1 (for. NET Core 1.1 Preview 1 SDK and runtime image) are: 1.0.0-preview2.1-sdk and 1.1.0-core.
Tags of the latest and other non-existing versions will not be updated to point to. NET core 1.1, but will still point to. NET core 1.0. Note that the. NET Core R & D team still decides that the no-version tag should always point to the LTS version (see the following explanation) or whether they can point to the current version.
You can use the dotnetapp-preview example in the. NET Core Docker Samples repository to try out a new Docker image. Other samples can be easily modified to exercise. NET Core 1.1 Preview 1 images. Follow the project. json upgrade instructions I gave you.
Current version
The. NET Core R & D team announced on April 9, July that it would adopt the dual-Line Strategy of the. NET Core version. At that time, they were called two different product series "LTS" and "FTS ". These terms have been changed to "long-term support (LTS)" and "current version ". This is similar to other platforms such as Red Hat Enterprise Linux, Ubuntu, and Node. js. In fact, the term "current" is used because it is already in use and has the desired meaning.
The. NET Core R & D team called different versions "trains" because it is easy to use trains (long vehicles on metal tracks) similar to software versions.
Although. The LTS (slow) and current (FAST) trains define different release rhythms, different expectations for acceptable change types in updates, and different support time frames. Based on the experience in the. NET Framework, there is only one train. the. NET Core R & D team hopes to have more flexibility in the release and better serve different customers.
After in-depth and lengthy tests, important customers use (named LTS) and ship the LTS version before high stability. Once released, the goal is to update the LTS version as few as possible. It is only used for security, reliability, performance problems, and rare important features. They support up to three years. More conservative customers expect zero changes, although they realize that this is not very realistic.
The current version is currently active. . NET core 1.1 is such a version. In these versions, major functions are executed and new operating system distribution is supported. These versions are stable, but the movement speed is much faster. Therefore, more tests are required when you use them. They are only supported three months after the next version is released. To retain the supported versions, you must move them to the next version three months ago. With Current, the new features you get must be faster, but you must stay on that release train.
Some new operating system releases will also be added to the LTS releases, but this will be completed based on exceptions. Windows Server 2016 and macOS sield are examples of this situation.
Once you are satisfied with a series of current versions and have enough feedback, the. NET Core R & D team marks the next version as LTS and repeats the entire process. This may occur after several or more current versions.
Switching from the current version to LTS is a good opportunity to "switch trains. It is expected that some developers will select the current version during the development of a longer project to obtain the latest features and a wider set of fixes, and then wait for the project later (assuming the timing is normal) prepare for production and deployment.
Version Control, file name and Docker tag
If you work on an important project with a large number of users and releases, you may know that product naming and version control are very difficult. The. NET Core project cannot solve this problem. In fact, it seems to include it. It is not so intuitive to select a version string.
There are two. NET core versions: One runtime and one SDK that contains runtime and some tools. So far, it is easy. The main problem is that SDK distribution is the most popular distribution, but it does not share the same version scheme with runtime. The challenge is to discuss the product mainly from the runtime version (including this blog article), while the SDK is developed based on the tool it carries. There are many reasons to do this. This is the context.
The. NET core installer, Docker image, and project. json file carry the version number and reason you need to use. Selecting and/or writing the right thing may be a challenge, because some of these strings seem very similar, but it means something different.
Here is the key version:
- 1.0.0-preview2-sdk-refers to. NET Core 1.0 SDK, which includes stable 1.0 Runtime and Preview 1.0 tools. This is the second preview version of. NET Core Tools.
- 1.0.0-preview2.1-sdk-Indicates. NET Core 1.1 SDK, which includes the 1.1 Runtime preview and 1.0 tool preview. It is called preview2.1 because it is a vertex-related tool relative to preview2, even if it comes with a new runtime.
- 1.1.0-preview1-indicates the first preview of. NET Core 1.1 Runtime.
The. NET Core R & D team plans to release the final version 1.0. NET Core tool next year. This situation should be better. It will enable us to send 1.0.0-sdk version without preview strings. The SDK and runtime version still do not match .. The NET Core R & D team is discussing how to do this. They want the tool to be a faster version than the runtime, but may choose to artificially make the version number the same from time to make Runtimes and SDK easier to match.
The. NET Core 1.1 Preview 1 upgrade announcement is complete. Next we will continue with the introduction of ASP. NET Core 1.1 Preview 1.
The following new features can be previewed in this version:
- URL rewriting Middleware
- Response cache Middleware
- Response compression Middleware
- WebListener Server
- Use view components as tag assistants
- Middleware as MVC Filter
- Cookie-based TempData provider
- View Compilation
- Azure App Service logging provider
- Azure keystore configuration provider
- Redis and Azure Storage Data Protection keystore
For more details about the changes in this version, see release notes.
Let's take a look at some features ready for trial in this preview:
URL rewriting Middleware
You can use IIS standard XML formatting rules, Apache Mod_Rewrite syntax, or some middleware components encoded into some simple C # Method Configuration in your application to bring the URL rewriting function to ASP.. NET Core. This allows you to map the public URL space designed for the client consumption to any representation of the downstream components required by the middleware pipeline, and redirect the client to different URLs according to the mode.
For example, you can ensure the canonical host name by overwriting any request to the http://example.com, and override the http://www.example.com for all content after the rewrite rule is run. Another example is to redirect all requests to the http://example.com to the https://example.com. You can even configure URL rewriting to apply these two rules and rewrite all requests to example.com to SSL and www.
We can use this middleware by adding a reference to the Web application of the Microsoft. AspNetCore. Rewrite package. This allows us to add a call to the Startup. Configure method of our override to Configure RewriteOptions:
using System.IO;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Rewrite;
namespace MyApplication {
public class Startup {
public void Configure (IApplicationBuilder app, IHostingEnvironment env)
{
var options = new RewriteOptions ()
.AddRedirect ("(. *) / $", "$ 1") // redirect using regular expression
.AddRewrite (@ "app / (\ d +)", "app? Id = $ 1", skipRemainingRules: false) // rewrite based on regular expression
.AddRedirectToHttps (302, 5001) // Redirect to another port and use HTTPS
.AddIISUrlRewrite (env.ContentRootFileProvider, "UrlRewrite.xml") // Configure using IIS UrlRewriter rules
.AddApacheModRewrite (env.ContentRootFileProvider, "Rewrite.txt"); // Configure using Apache mod_rewrite rule
app.UseRewriter (options);
}
// Other Code
}
}
startup.cs
As you can see, we can force rewrite and redirect with different rules.
- Url Redirect sends the HTTP 301 Moved Permanently status code to a client with a new address
- Url Rewrite provides a different URL for subsequent steps in the HTTP pipeline, spoofing it to think that the request has a different address.
Response cache Middleware
By. aspNetCore. responseCaching and Microsoft. extensions. caching. the Memory package is added to the application, and can now be activated in the application with the previous ASP. the OutputCache function of the NET version is similar to the response cache. You can add the middleware to the application in the Startup. ConfigureServices method, and Configure the response cache from the Startup. Configure method. For example implementation, see the demo in the ResponseCaching repository.
Response compression Middleware
Now, you can add GZipCompression to the ASP. net http pipeline, If you want ASP. NET to perform compression, rather than the front-end Web server. This middleware is provided in the Microsoft. AspNetCore. ResponseCompression package. You can add a simple GZipCompression at the fastest compression level with the following syntax in the Startup. cs class:
public class Startup {
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
public void Configure(IApplicationBuilder app)
{
app.UseResponseCompression();
// Other code
}
}
There are other options for configuring compression, including specifying the features of the custom compression provider.
WebListener server for Windows
WebListener is a Server that runs directly on the Windows Http Server API. WebListener provides options that take advantage of specific Windows features, such as support for Windows authentication, Port Sharing, HTTPS with SNI, HTTP/2 with TLS (Windows 10 ), direct File Transfer and response cache WebSockets (Windows 8 ). On Windows, you can use this Server instead of Kestrel. By referencing the Microsoft. AspNetCore. Server. WebListener package instead of the Kestrel package, and configuring WebHostBuilder to use Weblistener instead of Kestrel:
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseStartup<Startup>()
.UseWebListener(options =>
{
options.ListenerSettings.Authentication.Schemes = AuthenticationSchemes.None;
options.ListenerSettings.Authentication.AllowAnonymous = true;
})
.Build();
host.Run();
}
You can find other examples that demonstrate WebListener in its GitHub repository.
Unlike other software packages that are part of this version, WebListener is being previewed in the form of 1.0.0 and 1.1.0. Packages of version 1.0.0 can be used to produce LTS (1.0.1) ASP. NET Core applications. The package of version 1.1.0 preview is the prerelease version of the next version of WebListener, as part of version 1.1.0.
Use view components as tag assistants
Now, you can use the Tag Helper syntax to call the View component from the View and obtain all the advantages of the intelliisense and Tag Helper tool in Visual Studio. Previously, to call the View Component from the View, you will use the Component. InvokeAsync method and use an anonymous object to pass any View Component parameters:
@await Component.InvokeAsync("Copyright", new { website = "example.com", year = 2016 })
Instead, you can call the View Component just like you can get any tag assistant and get the intelliisense of the View Component parameter:
To enable the call to the View component as the tag assistant, you only need to use the @ addTagHelpers command to add the View component as the tag ASSISTANT:
@addTagHelper "*, WebApplication1"
Middleware as MVC Filter
Middleware is usually located in the global request processing pipeline. But what if you want to apply middleware only to specific controllers or operations? Now you can use the new MiddlewareFilterAttribute to apply the middleware to the MVC resource filter. For example, you can apply the response compression or cache to a specific operation, or use a request culture provider based on the routing value, and use localized middleware to create the current culture for the request.
To use middleware as a filter, you must first use the Configure method to create a type that specifies the middleware pipeline to be used:
public class LocalizationPipeline {
public void Configure(IApplicationBuilder applicationBuilder)
{
var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("fr")
};
var options = new RequestLocalizationOptions {
DefaultRequestCulture = new RequestCulture(culture: "en-US", uiCulture: "en-US"),
SupportedCultures = supportedCultures,
SupportedUICultures = supportedCultures
};
options.RequestCultureProviders = new[] { new RouteDataRequestCultureProvider() { Options = options } };
applicationBuilder.UseRequestLocalization(options);
}
}
Then, you can use MiddlewareFilterAttribute to apply the middleware pipeline to the Controller operation or global:
[Route("{culture}/[controller]/[action]")]
[MiddlewareFilter(typeof(LocalizationPipeline))]
public IActionResult CultureFromRouteData()
{
return Content($"CurrentCulture:{CultureInfo.CurrentCulture.Name},CurrentUICulture:{CultureInfo.CurrentUICulture.Name}");
}
Cookie-based TempData provider
As an alternative to storing TempData with session status, you can now use the new Cookie-based TempData provider. The Cookie-based TempData provider saves all TempData in cookies and does not need to manage the session Status of any server.
To use the Cookie-based TempData provider, register the CookieTempDataProvider service in the ConfigureServices method after adding the MVC service, as shown below:
services.AddMvc();services.AddSingleton<ITempDataProvider, CookieTempDataProvider>();
View Compilation
Although the view's razor Syntax provides a flexible development experience without a compiler, in some cases, you do not want to explain the razor syntax at runtime. You can now pre-compile the Razor view referenced by the application and deploy them using the application. You can add the view compiler to the application by referencing "Microsoft. AspNetCore. Mvc. Razor. Precompilation. tools" in the "Tools" section of project. json. After the program is restored, you can run "dotnet razor-precompile" to pre-compile the razor view in the application.
Azure App Service logging provider
The Microsoft. AspNetCore. AzureAppServicesIntegration package allows your applications to record and diagnose specific logs of the App Service. Any Log message abstracted using ILogger/ILoggerFactory will be transferred to the location configured in the diagnostic logs section of the App Service configuration in the portal (see the screen ).
Usage:
Add a reference to the Microsoft. AspNetCore. AzureAppServicesIntegration package and call the UseAzureAppServices method in Program. cs.
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseAzureAppServices()
.UseStartup<Startup>()
.Build();
host.Run();
}
program.cs
Note: UseIISIntegration is not in the above example because UseAzureAppServices includes it. If you have two calls but do not explicitly call UseIISIntegration, it should not hurt your application.
After the UseAzureAppServices method is added, your application complies with the settings in the diagnostic logs section of the Azure application service settings, as shown below. If you change these settings, such as switching from the file system to the blob storage log, your application will automatically switch to the new location without redeployment.
Azure keystore configuration provider
The Microsoft. Extensions. Configuration. AzureKeyVault package provides Configuration providers for the Azure keystore. This allows you to retrieve and save configurations from the key vault secret when an application is started in the memory, and access the configuration data using the common ASP. NET Core configuration abstraction.
The basic usage of the provider is as follows:
var builder = new ConfigurationBuilder ();
.AddJsonFile ("settings.json")
.AddKeyVault (
"<vault uri>", // URI of the keystore from which to retrieve keys
"<clientId>", // The client ID to be used to retrieve the key.
cert // x509 certificate for authentication with Azure AD
)
startup.cs
For an example of how to add a Key Vault configuration provider, see the example here:
Https://github.com/aspnet/Configuration/tree/dev/samples/KeyVaultSample
Redis and Azure Storage Data Protection keystore
Microsoft. AspNetCore. DataProtection. AzureStorage and Microsoft. AspNetCore. DataProtection. Redis packages allow you to store data protection locks in Azure storage or Redis respectively. This allows you to share keys between multiple instances of the website so that you can share authentication cookies or CSRF protection on multiple Server Load balancer instances running ASP. NET Core applications, for example. Since data protection is used behind the scenes in MVC, it is very likely that you will need to share the key ring once you start to scale out. Before the two packages, the option to share the key is to use the network sharing and file-based keystore.
Azure example
services.AddDataProtection() .AddAzureStorage(“<blob URI including SAS token>”);
Redis example
// Connect
var redis = ConnectionMultiplexer.Connect("localhost:6379");
// Configure
services.AddDataProtection()
.PersistKeysToRedis(redis, "DataProtection-Keys");
Note:: When a non-persistent Redis instance is used, nothing encrypted with Data Protection cannot be decrypted after the instance is reset. For the Default Authentication stream, this usually means that the user is redirected to another login. However, you cannot completely decrypt any content that is manually encrypted using the Data Protections Protect method. Therefore, when you manually use the Data Protection Protect method, do not use non-persistent Redis instances. Data protection is optimized for transient data.
Remarks
This article is an introduction to ASP. NET Core 1.1 Preview 1. I hope this article will help you. If you think it is good, please take a wave of attention or recommendations. If it is reprinted, enter the source http://www.cnblogs.com/smallprogram /.
This section describes. NET Core 1.1 Preview 1. To view the introduction to EntityFramework Core 1.1 Preview 1, click here.
Thank you again for reading this article.