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！
2016年10月25日發布.NET Core 1.1 Preview 1。 它包括對其他Linux發行版的支持，有很多更新，是當前的第一個版本。 將在下面描述所有這些變化。 該版本是一個預覽版本，目的是早期查看.NET Core 1.1版本。 它不是“Go Live”，並且不建議用於生產工作負載。
關於EntityFramework Core 1.1 Preview 1，可以參考之前的我的另一篇博文
您可以立即下載版本：:
您可以在.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版本是第一個1.x次要更新。 其主要產品主題是添加對新操作系統分發的支持。
增加了對以下分發版的支持:
您可以在.NET Core 1.1 Preview 1發行說明中查看完整的受支持發行版。
此版本中添加了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預覽1提交以了解更多。
以前發布的MSBuild和CSProj更改不是此版本的一部分，但仍然有效。
.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開始。 之後，您可以像使用.NET Core 1.0一樣使用.NET Core工具。 嘗試以下命令集來創建，構建和運行.NET Core 1.1 Preview 1應用程序：
dotnet new dotnet restore dotnet run
您可以查看dotnetapp-preview示例試用.NET Core 1.1預覽1應用程序，無論是否使用Docker。
您可以將現有的.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文件。
你也可以只寫1.1.0-preview1- *，跳過特定於構建的信息。 它的工作原理，使您能夠更容易地前進與.NET Core 1.1的構建，如果你采納那些。 當.NET Core 1.1作為穩定版本發布時，您將要將元包版本更改為1.1.0。 目標框架版本不會改變.NET Core 1.1的生命周期。
.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的轉換是“切換火車”的好機會。預計一些開發人員將在開發較長項目期間選擇當前版本，以獲得最新功能和更廣泛的修復集，然後在項目中稍後（假設計時正常）為其生產部署做好准備。
如果你在一個有大量用戶和發行版的重要項目上工作，你可能會知道產品命名和版本控制是非常困難的。 .NET Core項目不能解決這個問題。事實上，它似乎包含它，選擇版本字符串，不是那麼直觀。
有兩個.NET核心版本：一個運行時和一個包含運行時和一些工具的SDK。很容易到目前為止。主要的問題是SDK分發是最受歡迎的分發，但不與運行時共享相同的版本方案。面臨的挑戰是，主要從運行時版本（包括本博客文章）來討論產品，而SDK則根據其攜帶的工具進行版本化。有很多原因選擇這樣做。這就是上下文。
.NET核心安裝程序，Docker映像和project.json文件攜帶您需要使用的版本號和原因。選擇和/或寫正確的東西可能是挑戰，因為這些字符串中的一些看起來非常相似，但意味著不同的東西。
這裡是關鍵的版本：
.NET Core研發團隊打算明年發布最終的1.0版本的.NET核心工具。這種情況應該會更好。它將使我們能夠發送1.0.0-sdk版本，沒有預覽字符串。 SDK和運行時版本仍將不匹配。.NET Core研發團隊正在討論怎麼做。他們希望工具能夠比運行時更快的版本，但是，可能會選擇不時地人為地使版本號相同，以使Runtimes和SDK更容易匹配。
以下新功能可在此版本中預覽：
有關此版本中包含的更改的其他詳細信息，請查看發行說明。
讓我們看看准備好在這個預覽中試用的一些功能：
通過可以使用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
}
}startup.cs
正如你所看到的，我們可以用不同的規則強制重寫和重定向。
通過將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
}
}
還有其他可用於配置壓縮的選項，包括指定自定義壓縮提供程序的功能。
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"
中間件通常位於全局請求處理管道中。 但是如果你想將中間件只應用於特定的控制器或操作呢？ 您現在可以使用新的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}");
}
作為使用會話狀態存儲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”來預編譯應用程序中的剃刀視圖。
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存儲日志，您的應用程序將自動切換到記錄到新位置，而不重新部署。
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
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 Preview 1的簡介，希望本文對你有所幫助。如果您覺得不錯，請點一波關注或推薦。如果轉載，請注明出處http://www.cnblogs.com/smallprogram/。
本文中間穿插簡介了.NET Core 1.1 Preview 1。如果需要查看EntityFramework Core 1.1 Preview 1的簡介，請點擊此處。
再次感謝您的閱讀。
