ASP.NET Core 1.1 简介

ispsh

　　ASP.NET Core 1.1 于2016年11月16日发布。这个版本包括许多伟大的新功能以及许多错误修复和一般的增强。这个版本包含了多个新的中间件组件、针对Windows的WebListener服务器、Razor视图编译以及Azure相关的特性。要将现有项目更新到ASP.NET Core 1.1 ，您需要执行以下操作：
　　1. 下载并安装更新的.NET Core 1.1  SDK
2. 按照.NET Core 1.1 升级公告(下一节介绍)中的说明将项目更新为使用.NET Core 1.1
3. 更新您的ASP.NET Core包依赖项以使用新的1.1.0 版本
　　注意：要在Visual Studio中使用NuGet包管理器将包更新到1.1 ，您需要从nuget.org下载并安装用于nuget  3.5 。你现在应该准备试试1.1！
　　新的中间件组件和增强
　　在这个版本中，我们能够在特定的控制器或action中使用中间件组件。组件可以借助新的MiddlewareFilterAttribute担当MVC资源过滤器的角色。例如，响应压缩和缓存这样的功能可以配置在特定的action或控制器中，而不是配置在整个应用的级别上。
　　在之前的几个版本中，URL重写（URL rewriting）就已经成为IIS的一项特性了，它是作为一个http模块来实现的。在这个预览版本中，URL重写作为一个中间件组件重新回归了。这个组件可以配置为使用IIS标准的XML格式化规则、Apache Mod_Rewrite语法，也可以直接使用Web应用中的C#方法。
　　ASP.NET Core 1.1还带来了两个新的中间件，也就是响应缓存（response caching）和响应压缩（response compression）。响应缓存中间件会作为ASP.NET MVC中OutputCacheAttribute的继任者。

URL重写中间件
　　通过可以使用IIS标准XML格式化规则，Apache Mod_Rewrite语法或一些编码到您的应用程序中的一些简单的C＃方法配置的中间件组件将URL重写功能带到ASP.NET Core。这允许将设计用于客户端消耗的公共URL空间映射到中间件流水线所需的下游组件的任何表示，以及根据模式将客户端重定向到不同的URL。
　　例如，您可以通过重写对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.xml")        // 使用IIS UrlRewriter规则进行配置
                .AddApacheModRewrite(env.ContentRootFileProvider, "Rewrite.txt");       // 使用Apache mod_rewrite规则进行配置
app.UseRewriter(options);
}
// Other Code
}
}
正如你所看到的，我们可以用不同的规则强制重写和重定向。

• 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
}
}
　　还有其他可用于配置压缩的选项，包括指定自定义压缩提供程序的功能。
　　Razor视图编译
　　在ASP.NET MVC之前的版本中，有一种预编译Web站点的方式，这样的话，视图编译就可以在部署阶段执行，而不是在运行期。通过这种方式，能够减少部署后首次加载页面所造成的延迟。ASP.NET Core 1.1重新带回了预编译Razor视图的功能。这个视图编译器要添加到应用的project.json文件的“tools”部分，并且要带有对工具包的引用。在运行package restore之后，dotnet razor-precompile命令就可以预编译razor视图了。

将视图组件用作标签助手
　　现在，您可以使用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}");
}
　　虽然视图的razor语法提供了不需要编译器的灵活开发体验，但在某些情况下，您不希望在运行时解释razor语法。 您现在可以预先编译应用程序引用的Razor视图，并使用应用程序部署它们。 您可以在project.json的“tools”部分中使用包引用“Microsoft.AspNetCore.Mvc.Razor.Precompilation.Tools”将视图编译器添加到应用程序。 运行程序包恢复后，您可以执行“dotnet razor-precompile”来预编译应用程序中的剃刀视图。
　　针对Windows的WebListener服务器
　　WebListener是构建在Windows Http Server API之上的服务器。WebListener提供了依赖于平台的特性，比如Windows authentication、端口共享（port sharing）、结合SNI的HTTPS、基于TLS的HTTP/2（Windows 10）、直接的文件传输以及WebSockets的响应缓存（Windows 8）。

用于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应用程序。  
　　Azure相关的特性
　　AzureAppServicesIntegration包允许发送日志到Azure App Service中。要写入的所有日志信息都会使用ILogger/ILoggerFactory抽象，在Azure门户的App Service配置中，Diagnostics Logs区域设置了这些日志将会写入到什么位置中。
　　AzureKeyVault包带来了一个针对Azure Key Vault的配置提供者（configuration provider ）。这样的话，就允许我们在应用启动的时候从Key Vault secrets中获取配置，并将其放在内存之中，从而能够使用正常的ASP.NET Core配置抽象来访问配置数据。
　　ASP.NET Core引入了DataProtection，它提供了加密相关的API。这个预览版本包含了两个包，允许将数据保护的key（Data Protection key）存储到Azure Storage和Redis中。这样的话，能够跨多个Web站点实例来共享key，也能够在负载均衡的场景下跨多台服务器进行共享。

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();
}
　　注意：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证书
)
　　有关如何添加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示例

// Connect
var redis = ConnectionMultiplexer.Connect("localhost:6379");
// Configure
services.AddDataProtection()
.PersistKeysToRedis(redis, "DataProtection-Keys");

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

备注
　　本文是针对ASP.NET Core 1.1 的简介，希望本文对你有所帮助