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的繼任者。
通過可以使用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
}
}
正如你所看到的，我們可以用不同的規則強制重寫和重定向。
通過將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"
中間件通常位於全局請求處理管道中。 但是如果你想將中間件只應用於特定的控制器或操作呢？ 您現在可以使用新的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）。
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，也能夠在負載均衡的場景下跨多台服務器進行共享。
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存儲日志，您的應用程序將自動切換到記錄到新位置，而不重新部署。
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
Microsoft.AspNetCore.DataProtection.AzureStorage和Microsoft.AspNetCore.DataProtection.Redis軟件包允許將數據保護鎖分別存儲在Azure存儲或Redis中。 這允許在網站的多個實例之間共享密鑰，以便您可以例如在運行ASP.NET Core應用程序的多個負載平衡服務器上共享認證cookie或CSRF保護。 由於數據保護在幕後用於MVC中的一些事情，極有可能一旦你開始向外擴展，你將需要共享鑰匙圈。 在這兩個包之前共享密鑰的選項是使用網絡共享與基於文件的密鑰存儲庫。
services.AddDataProtection() .AddAzureStorage(“<blob URI including SAS token>”);
// 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 的簡介，希望本文對你有所幫助
