ASP.NET Core 1.1 Preview 1 简介(包含.NETCore 1.1升级公告)

ASP .NET Core 1.1 Preview 1于2016年10月25日发布。这个版本包括许多伟大的新功能以及许多错误修复和一般的增强。

要将现有项目更新到ASP.NET Core 1.1 Preview 1，您需要执行以下操作：

1. 下载并安装更新的.NET Core 1.1 Prevew 1 SDK
2. 按照.NET Core 1.1 Preview 1升级公告(下一节介绍)中的说明将项目更新为使用.NET Core 1.1 Preview 1
3. 更新您的ASP.NET Core包依赖项以使用新的1.1.0-preview1版本

注意：要在Visual Studio中使用NuGet包管理器将包更新到1.1 Preview 1，您需要从nuget.org下载并安装用于Visual Studio 2015 3.5 RC1或更高版本的NuGet包管理器。

你现在应该准备试试1.1！

.NET Core 1.1 Preview 1升级公告

2016年10月25日发布.NET Core 1.1 Preview 1。它包括对其他Linux发行版的支持，有很多更新，是当前的第一个版本。将在下面描述所有这些变化。该版本是一个预览版本，目的是早期查看.NET Core 1.1版本。它不是“Go Live”，并且不建议用于生产工作负载。

关于EntityFramework Core 1.1 Preview 1，可以参考之前的我的另一篇博文

您可以立即下载版本：:

Windows x64
Windows x86
macOS x64
Linux x64

您可以在.NET Core预览下载页面上查看完整的.NET Core 1.1下载。

.NET Core 1.1预览1 Docker中的Docker镜像也可以在microsoft / dotnet仓库中找到。您可以在.NET Core Docker Samples存储库中使用dotnetapp-preview示例查看新的Docker镜像。

您可以在dot.net/core页面上找到现有的.NET Core 1.0版本。 .NET Core 1.1在作为稳定版本发布后也将列在该页面上。

.NET Core 1.1 Preview 1改进

.NET Core 1.1版本是第一个1.x次要更新。其主要产品主题是添加对新操作系统分发的支持。

.NET Core 1.1 Preview 1操作系统分发

增加了对以下分发版的支持:

Linux Mint 18
OpenSUSE 42.1
macOS 10.12
Windows Server 2016

您可以在.NET Core 1.1 Preview 1发行说明中查看完整的受支持发行版。

.NET Core 1.1 Preview 1 APIs

此版本中添加了1380个API。您可以在API差异.NET核心应用程序1.0（参考）VS .NET核心应用程序1.1（参考）文档中查看完整的集。

添加了API以启用特定场景。 API添加没有特定的主题。

.NET Standard 1.6.1-preview1作为此版本的一部分发布。仍然.NET标准2.0支持。

.NET Core 1.1 Preview 1修复

进行了许多具体的产品更改。您可以查看完整的.NET Core 1.1预览1提交以了解更多。

以前发布的MSBuild和CSProj更改不是此版本的一部分，但仍然有效。

.NET Core 1.1 Preview 1 并行安装使用.NET Core 1.0

.NET Core 1.1预览1与.NET Core 1.0并行安装。 .NET Core 1.0应用程序将继续使用.NET Core 1.0运行时。 .NET Core 1.0环境被设计为几乎完全不知道也安装了稍后的次要或主要版本。

只有一个命令 - dotnet new - 将随着安装.NET Core 1.1的变化而改变。 dotnet new将创建需要.NET Core 1.1 Preview 1的新项目，而不是.NET Core 1.0。因此，您可能希望避免将其安装在使用命令行工具进行基于.NET Core 1.0的开发的机器上。如果你是在Windows上，并使用Visual Studio创建新项目，而不是dotnet新，安装.NET Core 1.1是个好主意。

dotnet new将为安装的最新.NET Core版本创建新项目。

.NET Core 1.1 Preview 1试试看

您可以从安装.NET Core 1.1 Preview开始。之后，您可以像使用.NET Core 1.0一样使用.NET Core工具。尝试以下命令集来创建，构建和运行.NET Core 1.1 Preview 1应用程序：

dotnet newdotnet restoredotnet run

您可以查看dotnetapp-preview示例试用.NET Core 1.1预览1应用程序，无论是否使用Docker。

.NET Core 1.1 Preview 1升级现有项目

您可以将现有的.NET Core项目从使用.NET Core 1.0升级到.NET Core 1.1 Preview 1.我将向您展示dotnet new命令现在生成的新project.json文件。这是查看需要复制/粘贴到现有project.json文件中的新版本值的最佳方法。目前没有自动化工具将现有项目升级到更高版本的.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"  } }}

这个project.json文件与.NET Core 1.0 project.json非常相似，除了netcoreapp1.1和1.1.0-preview1-001100-00目标框架和元包版本字符串。

您可以使用以下替换来帮助您更新要临时或永久移动到.NET Core 1.1的project.json文件。

将netcoreapp1.0目标框架更新为netcoreapp1.1。
将Microsoft.NETCore.App包版本从1.0.x（例如，1.0.0或1.0.1）更新到1.1.0-preview1-001100-00。

你也可以只写1.1.0-preview1- *，跳过特定于构建的信息。它的工作原理，使您能够更容易地前进与.NET Core 1.1的构建，如果你采纳那些。当.NET Core 1.1作为稳定版本发布时，您将要将元包版本更改为1.1.0。目标框架版本不会改变.NET Core 1.1的生命周期。

升级到.NET Core 1.1 Preview 1 Docker镜像

.NET Core 1.1预览1图像已发布到microsoft / dotnet仓库。 .NET Core 1.1的两个新标签（用于.NET Core 1.1 Preview 1 SDK和运行时映像）分别为：1.0.0-preview2.1-sdk，1.1.0-core。

最新的和其他无版本的标签不会被更新为指向.NET核心1.1，但仍指向.NET核心1.0。注意，.NET Core研发团队仍然决定无版本标签应该总是指向LTS版本（见下面的解释），或者它们是否可以指向当前版本。

您可以使用.NET Core Docker Samples存储库中的dotnetapp-preview示例来试用新的Docker镜像。其他样本可以很容易地修改，以锻炼.NET Core 1.1 Preview 1 images，按照我给你上面的project.json升级说明。

当前版本

.NET Core研发团队在7月宣布，将采用.NET核心版本的双列战略。当时，称之为两种不同的产品系列“LTS”和“FTS”。这些发布条款已更名为“长期支持（LTS）”和“当前版本”。这与其他平台类似，如Red Hat Enterprise Linux，Ubuntu和Node.js。事实上，采用“当前”，因为该术语已经在使用，并已经具有想要的意思。

.NET Core研发团队称不同的版本为“trains”，因为它很容易应用火车（长的车辆在金属轨道上）类似于软件版本。

虽然。 LTS（慢）和当前（快）列车定义不同的释放节奏，对更新中可接受的变化种类的不同期望以及不同的支持时间帧。根据在.NET Framework中的经验，只有一个列车，.NET Core研发团队希望在发布中有更多的灵活性，并能够更好地服务于不同的客户。

在经过深入，冗长的测试，重要的客户采用（被命名为LTS）和高度稳定性之前发运LTS版本。一旦发布，目标是尽可能少地更新LTS版本，仅用于安全性，可靠性，性能问题和罕见的重要功能。他们支持长达三年。更保守的客户期望零变化，虽然他们意识到这不是很现实。

当前版本是目前正在积极工作的版本。 .NET核心1.1是这样的版本。在这些版本中执行主要功能工作，并且还支持新的操作系统分发。这些版本是稳定的，但是移动速度也快得多，因此当您采用它们时需要更多的测试。它们也仅在下一个最新版本发布后三个月才得到支持。要保留受支持的版本，您需要在三个月过去之前移动到下一个当前版本。有了Current，你得到的新功能必须更快，但必须留在那个发行火车。

支持一些新的操作系统发行版也将在LTS发行版中添加，但这将在异常基础上完成。 Windows Server 2016和macOS Sierra是发生这种情况的示例。

一旦对一系列当前版本感到满意，并且有足够的反馈，.NET Core研发团队将下一个版本标记为LTS，然后重复整个过程。这可能发生在连续几个或许多当前版本之后。

当前版本到LTS的转换是“切换火车”的好机会。预计一些开发人员将在开发较长项目期间选择当前版本，以获得最新功能和更广泛的修复集，然后在项目中稍后（假设计时正常）为其生产部署做好准备。

版本控制，文件名和Docker标签

如果你在一个有大量用户和发行版的重要项目上工作，你可能会知道产品命名和版本控制是非常困难的。 .NET Core项目不能解决这个问题。事实上，它似乎包含它，选择版本字符串，不是那么直观。

有两个.NET核心版本：一个运行时和一个包含运行时和一些工具的SDK。很容易到目前为止。主要的问题是SDK分发是最受欢迎的分发，但不与运行时共享相同的版本方案。面临的挑战是，主要从运行时版本（包括本博客文章）来讨论产品，而SDK则根据其携带的工具进行版本化。有很多原因选择这样做。这就是上下文。

.NET核心安装程序，Docker映像和project.json文件携带您需要使用的版本号和原因。选择和/或写正确的东西可能是挑战，因为这些字符串中的一些看起来非常相似，但意味着不同的东西。

这里是关键的版本：

1.0.0-preview2-sdk - 指.NET Core 1.0 SDK，其中包括稳定的1.0 Runtime和预览1.0工具。这是.NET Core Tools的第二个预览版本。
1.0.0-preview2.1-sdk - 指.NET Core 1.1 SDK，其中包括预览1.1 Runtime和预览1.0工具。它被称为preview2.1，因为它是一个点相关的工具相对于preview2，即使它带有一个新的运行时。
1.1.0-preview1 - 指的是.NET Core 1.1 Runtime的第一个预览。

.NET Core研发团队打算明年发布最终的1.0版本的.NET核心工具。这种情况应该会更好。它将使我们能够发送1.0.0-sdk版本，没有预览字符串。 SDK和运行时版本仍将不匹配。.NET Core研发团队正在讨论怎么做。他们希望工具能够比运行时更快的版本，但是，可能会选择不时地人为地使版本号相同，以使Runtimes和SDK更容易匹配。

.NET Core 1.1 Preview 1升级公告介绍完毕，下面继续之前的ASP.NET Core 1.1 Preview 1的简介

新的东西

以下新功能可在此版本中预览：

URL重写中间件
响应缓存中间件
响应压缩中间件
WebListener服务器
将视图组件用作标签助手
中间件作为MVC过滤器
基于Cookie的TempData provider
查看编译
Azure App Service日志记录提供程序
Azure密钥库配置提供程序
Redis和Azure存储数据保护密钥库

有关此版本中包含的更改的其他详细信息，请查看发行说明。

让我们看看准备好在这个预览中试用的一些功能：

URL重写中间件

通过可以使用IIS标准

例如，您可以通过重写对http://example.com的任何请求来确保规范主机名，而在重写规则运行后为所有内容重写http://www.example.com。另一个示例是将所有请求重定向到http://example.com到https://example.com。您甚至可以配置URL重写，以便应用这两个规则，并且对example.com的所有请求始终重定向到SSL并重写为www。

我们可以通过添加对Microsoft.AspNetCore.Rewrite包的Web应用程序的引用来开始使用此中间件。这允许我们在我们的重写器的Startup.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")          // 使用正则表达式重定向

        .AddRewrite(@"app/(\d+)", "app?id=$1", skipRemainingRules: false) // 基于正则表达式重写        .AddRedirectToHttps(302, 5001)         // 重定向到其他端口并使用HTTPS

        .AddIISUrlRewrite(env.ContentRootFileProvider, "UrlRewrite.")    // 使用IIS UrlRewriter规则进行配置

        .AddApacheModRewrite(env.ContentRootFileProvider, "Rewrite.txt");    // 使用Apache mod_rewrite规则进行配置      app.UseRewriter(options);    }        // Other Code    }  }

startup.cs

正如你所看到的，我们可以用不同的规则强制重写和重定向。

Url Redirect将HTTP 301 Moved Permanently状态代码发送到具有新地址的客户端
Url Rewrite为HTTP管道中的后续步骤提供了一个不同的URL，欺骗它认为请求了不同的地址。

响应缓存中间件

通过将Microsoft.AspNetCore.ResponseCaching和Microsoft.Extensions.Caching.Memory包添加到应用程序中，现在可以在应用程序中激活与之前的ASP.NET版本的OutputCache功能类似的响应缓存。您可以在Startup.ConfigureServices方法中将此中间件添加到应用程序，并从Startup.Configure方法配置响应缓存。对于示例实现，请查看ResponseCaching存储库中的演示。

响应压缩中间件

现在，您可以将GZipCompression添加到ASP.NET HTTP管道，如果您希望ASP.NET执行压缩，而不是前端Web服务器。此中间件在Microsoft.AspNetCore.ResponseCompression包中提供。您可以在Startup.cs类中使用具有以下语法的最快压缩级别添加简单的GZipCompression：

public class Startup {  public void ConfigureServices(IServiceCollection services)   {    services.AddResponseCompression();      }  public void Configure(IApplicationBuilder app)   {    app.UseResponseCompression();    // Other code  }}

还有其他可用于配置压缩的选项，包括指定自定义压缩提供程序的功能。

用于Windows的WebListener服务器

WebListener是直接在Windows Http Server API之上运行的服务器。 WebListener提供了利用Windows特定功能的选项，如支持Windows身份验证，端口共享，带有SNI的HTTPS，TLS的HTTP / 2（Windows 10），直接文件传输和响应缓存WebSockets（Windows 8）。在Windows上，您可以使用此服务器而不是Kestrel，通过引用Microsoft.AspNetCore.Server.WebListener包而不是Kestrel包，并将WebHostBuilder配置为使用Weblistener而不是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();}

您可以在其GitHub存储库中找到演示使用WebListener的其他示例。

与作为此版本的一部分的其他软件包不同，WebListener正以1.0.0和1.1.0预览的形式提供。 1.0.0版本的包可用于生产LTS（1.0.1）ASP.NET Core应用程序。 1.1.0预览版本的软件包是下一版本的WebListener的预发布版本，作为1.1.0版本的一部分。

将视图组件用作标签助手

现在，您可以使用Tag Helper语法从视图中调用View组件，并在Visual Studio中获得IntelliSense和Tag Helper工具的所有优点。以前，要从视图调用View组件，您将使用Component.InvokeAsync方法，并使用匿名对象传递任何View组件参数：

@await Component.InvokeAsync("Copyright", new { website = "example.com", year = 2016 })

相反，您现在可以像获取任何标记助手一样调用View组件，同时获取View Component参数的Intellisense：

要启用将View组件调用为标签助手，只需使用@addTagHelpers指令将View组件添加为标签助手：

@addTagHelper "*, WebApplication1"

中间件作为MVC过滤器

中间件通常位于全局请求处理管道中。但是如果你想将中间件只应用于特定的控制器或操作呢？您现在可以使用新的MiddlewareFilterAttribute将中间件应用为MVC资源过滤器。例如，您可以将响应压缩或缓存应用于特定操作，也可以使用基于路由值的请求文化提供程序，使用本地化中间件为请求建立当前文化。

要使用中间件作为过滤器，您首先使用Configure方法创建一个类型，该方法指定要使用的中间件管道：

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);      }}

然后，您可以使用MiddlewareFilterAttribute将该中间件流水线应用于控制器操作或全局：

[Route("{culture}/[controller]/[action]")][MiddlewareFilter(typeof(LocalizationPipeline))]public IActionResult CultureFromRouteData() { return Content($"CurrentCulture:{CultureInfo.CurrentCulture.Name},CurrentUICulture:{CultureInfo.CurrentUICulture.Name}");}

基于Cookie的TempData provider

作为使用会话状态存储TempData的替代方法，您现在可以使用新的基于Cookie的TempData提供程序。基于Cookie的TempData提供程序将所有TempData保存在cookie中，并且不需要管理任何服务器端会话状态。

要使用基于Cookie的TempData提供程序，请在添加MVC服务后在ConfigureServices方法中注册CookieTempDataProvider服务，如下所示：

services.AddMvc();services.AddSingleton<ITempDataProvider, CookieTempDataProvider>();

查看编译

虽然视图的razor语法提供了不需要编译器的灵活开发体验，但在某些情况下，您不希望在运行时解释razor语法。您现在可以预先编译应用程序引用的Razor视图，并使用应用程序部署它们。您可以在project.json的“tools”部分中使用包引用“Microsoft.AspNetCore.Mvc.Razor.Precompilation.Tools”将视图编译器添加到应用程序。运行程序包恢复后，您可以执行“dotnet razor-precompile”来预编译应用程序中的剃刀视图。

Azure App Service日志记录提供程序

Microsoft.AspNetCore.AzureAppServicesIntegration包允许您的应用程序利用App Service特定的日志记录和诊断。使用ILogger / ILoggerFactory抽象编写的任何日志消息将转到门户中App Service配置的“诊断日志”部分中配置的位置（请参阅屏幕截图）。

用法：

添加对Microsoft.AspNetCore.AzureAppServicesIntegration包的引用，并调用Program.cs中的UseAzureAppServices方法。

public static void Main(string[] args) { var host = new WebHostBuilder()  .UseKestrel()  .UseAzureAppServices()  .UseStartup<Startup>()  .Build();  host.Run(); }

program.cs

注意：UseIISIntegration不在上述示例中，因为UseAzureAppServices包括它，如果您有两个调用，但不显式调用UseIISIntegration不应该不会伤害您的应用程序。

添加UseAzureAppServices方法后，您的应用程序将遵守Azure应用程序服务设置的诊断日志部分中的设置，如下所示。如果更改这些设置，例如，从文件系统切换到blob存储日志，您的应用程序将自动切换到记录到新位置，而不重新部署。

Azure密钥库配置提供程序

Microsoft.Extensions.Configuration.AzureKeyVault包为Azure密钥库提供配置提供程序。这允许您从应用程序启动时从密钥保险库秘密检索配置并将其保存在内存中，使用普通的ASP.NET Core配置抽象来访问配置数据。

提供者的基本用法是这样的：

var builder = new ConfigurationBuilder();  .AddJsonFile("settings.json")  .AddKeyVault(    "<vault uri>", //要从中检索密钥的密钥库的URI    "<clientId>", //要用于检索密钥的客户端ID。    cert //用于使用Azure AD进行身份验证的x509证书  )

startup.cs

有关如何添加Key Vault配置提供程序的示例，请参阅此处的示例：

https://github.com/aspnet/Configuration/tree/dev/samples/KeyVaultSample

Redis和Azure存储数据保护密钥库

Microsoft.AspNetCore.DataProtection.AzureStorage和Microsoft.AspNetCore.DataProtection.Redis软件包允许将数据保护锁分别存储在Azure存储或Redis中。这允许在网站的多个实例之间共享密钥，以便您可以例如在运行ASP.NET Core应用程序的多个负载平衡服务器上共享认证cookie或CSRF保护。由于数据保护在幕后用于MVC中的一些事情，极有可能一旦你开始向外扩展，你将需要共享钥匙圈。在这两个包之前共享密钥的选项是使用网络共享与基于文件的密钥存储库。

Azure示例

services.AddDataProtection() .AddAzureStorage(“<blob URI including SAS token>”);

Redis示例

// Connectvar redis = ConnectionMultiplexer.Connect("localhost:6379");// Configureservices.AddDataProtection() .PersistKeysToRedis(redis, "DataProtection-Keys");

注意：当使用非持久性Redis实例时，使用Data Protection加密的任何内容将无法在实例重置后解密。对于默认的认证流，这通常只是意味着用户被重定向到再次登录。但是，对于使用Data Protections Protect方法手动加密的任何内容，您将无法完全解密数据。因此，当手动使用Data Protection的Protect方法时，不应使用不持久的Redis实例。数据保护针对短暂数据进行了优化。