文章出處

本篇博文目錄：

  • ASP.NET 5 模版
  • ASP.NET 5 目錄結構
  • 前端管理工具
  • 無編譯開發
  • Microsoft Git Provider
  • 智能感知和錯誤信息
  • Smart Unit Testing
  • 等待發現。。。

Visual Studio 2015 Preview 版本部分說明：

  • ASP.NET 5 Preview runtime with VS2015 Preview only.
  • ASP.NET 5 Preview tooling with VS2015 Preview only.
  • ASP.NET tooling update for both VS2015 Preview and VS2013 Update 4.
  • ASP.NET runtime updates, most of which are in VS2013 Update 4 as well.
  • WebForm 4.6 improvement for VS2015 Preview only

在以上版本說明中，注意反復出現的關鍵詞“only”，也就是說，如果你想要體驗這次微軟發布的一系列新的東西，比如：C# 6.0、ASP.NET 5、EntityFramework 7.0 等（Visual Studio 其他版本暫不支持），那么首先你需要下載并安裝 Visual Studio 2015 Preview。

在以往微軟發布或更新 Visual Studio 版本時，我們開發 ASP.NET 應用程序，帶給我們的變化其實并不是很大，或者說你根本就感受不到變化，你感受到的只是下載安裝了幾個 G 的 Update 更新包，但這次微軟發布更新的 ASP.NET，無疑是巨大的，首先我們來看下 ASP.NET 5 的新功能介紹：

  • Web Forms、MVC 和 Web API 統一編程模型。
  • 無編譯開發體驗（no-compile），修改代碼文件，無需編譯，只需要瀏覽器刷新即可。
  • 無縫云開發支持（Cloud-ready environment configuration）。
  • 新的 HTTP 請求管道（更快）。
  • 內置依賴注入。
  • NuGet 管理一切，甚至是運行時本身。
  • 在 IIS 中運行，或自托管（self-hosted）在進程中。
  • GitHub 開源，意味著你可以查看源代碼，或貢獻自己的代碼。
  • ASP.NET 5 運行在 .NET Framework 或 .NET Core 的 Windows 上（關鍵詞：.NET Core）。
  • .NET Core 支持并行版本（side-by-side versioning）。
  • ASP.NET 5 可以運行在 OS X 和 Linux（Mono 運行時）。

下面我們看下使用 VS2015 開發 ASP.NET 5 過程中，有哪些“新鮮”的東西。

ASP.NET 5 模版

VS2013 新建 ASP.NET 項目：

VS2015 新建 ASP.NET 5 項目：

從圖中就可以看到，使用 VS 2015 新建 ASP.NET 5 項目，我們并不能像 VS 2013 那樣可以選擇 Web Forms、Web Api，也就是說 ASP.NET 5 是把 Web Forms、MVC 和 Web Api 強制集成到一塊的，并沒有分開創建各自項目的選擇，我們也可以從命名空間上可以看出，比如 VS 2013 新建的 ASP.NET 項目。

  • MVC 路由配置命名空間為：System.Web.Mvc;
  • Web Api 路由配置命名空間為： System.Web.Http;

而在 ASP.NET 5 中，所有的路由配置命名空間統一為：Microsoft.AspNet.Routing; 路由配置示例代碼：

app.UseMvc(routes =>
{
    //MVC Route
    routes.MapRoute(
        name: "default",
        template: "{controller}/{action}/{id?}",
        defaults: new { controller = "Home", action = "Index" });

    //Web Api Route
    routes.MapWebApiRoute("DefaultApi", "api/{controller}/{id?}");
});

ASP.NET 5 目錄結構

新建 ASP.NET 5 項目，解決方案目錄結構：

這邊簡單說一下我所了解到的，不一定準確，僅作參考：

global.json

global.json 文件存放在“Solution Items”解決方案目錄下，“to make better support for project-to-project references. It contains “sources”: [“src”] element, indicating the “src” folder as the parent folder for looking for project references.”，這段是我在 MSDN 一篇博文中摘錄的，新建項目的時候，你會發現在 global.json 中，默認有這樣的配置：

{
    "sources": [ "src", "test" ]
}

僅有的一段配置，我所理解的是 sources 表示此解決方案下的目錄結構，src 為解決方案目錄（從上面的示意圖就可以看出），test 為此 sources 的別名，如果有多個解決方案目錄，直接在 global.json 文件中添加 sources 配置即可，有人可能會問？為什么要這樣進行配置？所有的的項目管理不都是在 *.sln 中進行配置的嗎？用記事本打開 ASP.NET5.sln 文件，摘取一段配置：

Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{F96F5906-2577-49AD-9693-1809EF74348E}"
    ProjectSection(SolutionItems) = preProject
        global.json = global.json
    EndProjectSection
    ProjectSection(FolderGlobals) = preProject
        __JSONSchema = http://json.schemastore.org/global
    EndProjectSection
EndProject

這段配置其實我不是很懂，但看起來和在 MAC OS 中 Sublime Text 中開發 ASP.NET vNext 項目所保存的 *.sln 非常相似，這意味著什么呢？是不是說明跨平臺開發的 ASP.NET vNext 項目，可以使用不同的開發工具打開？這個我沒有試過，不過從 json 格式的 global.json 項目配置文件就可以看出一點，我覺得這個如果可以的話（可以意味著可能），將是非常棒的！

wwwroot

wwwroot 可以看作是 ASP.NET 5 變化點中提到的自托管（self-hosted），我自己暫時沒有對這個進行研究，你可以看一下 wwwroot 中具體的文件目錄，其實除了靜態文件（CSS、JS等），其他并沒有什么了，也沒有我們常見的 bin 文件夾下的一大堆程序集文件，使用 VS2015 發布應用程序，也會生成一個 wwwroot 文件夾，不過與解決方案中 wwwroot 不同的是，發布后的文件夾多了一個 bin 文件，其中只有一個 AspNet.Loader.dll 程序集，AspNet.Loader.dll 是什么東西？我也不是很清楚，Google 搜索了下，又發現幾個關鍵詞：OWIN、Helios，然后又發現了一篇非常棒的文章，摘錄一段：

Helios runtime without OWIN.
In this section we use the Helios runtime assembly named Microsoft.AspNet.Loader.IIS.dll that is a standalone assembly and it does not have the direct integration with the OWIN pipeline. The application uses the APIs exposed by the Helios rather then using the OWIN extensibility points by the Microsoft.Owin.Host.IIS.

另外，在新建 ASP.NET5 項目的屬性頁，有一個這樣的配置：

摘錄自張善友一篇博文的部分文字：

K Runtime Environment（KRE）這是一個命令行環境,將構建并運行(不再有真正的區別)從他們的新 project.json 。ASP.NET vNext 將 packages.config、NuGet 配置（nuspec）以及項目文件（csprojs）合并到統一的項目依賴配置文件 project.json 中。有個簡單的應用程序 K Version Manager (KVM) 負責安裝 KRE，可以安裝多個版本的 KRE，并可以在他們之間自由切換。

在 KRE target version 中有四個配置選項，默認選項配置為：KRE-CLR-x86.1.0.0-beta1，這部分內容我沒有找到相關資料說明，我只在 MSDN 中找到一篇不相關博文的部分說明（并沒有具體說明不同選項的不同之處）：The ASP.NET 5 Application's Property Page is a tool window and can be used to specify the KRE target version, the debug target, and whether binaries and NuGet packages should be created during a Visual Studio build.

Dependencies、References

Dependencies 翻譯為”依賴“，References 翻譯為“引用”，Dependencies 下有兩個“目錄”：Bower 和 NPM，簡單說就是 Bower 下為前端文件（CSS、JS），也可以為前端框架，如 bootstrap，通過 bower.json 進行配置加載，NPM（Node Package Manage）Node.js 的包管理器，可以理解為前端包管理器，通過 package.json 進行配置，以上都是 VS2015 對前端管理增加的新的東西，有些還不是微軟自己的東西，我也是剛開始學習，具體怎么配置管理，后面有說明。

References 就是我們一般見到的“Bin”或“引用”，和之前不同的是，目錄中只有 ASP.NET 5.0 和 ASP.NET Core 5.0，其中所有的程序集都是通過 project.json 文件中的 dependencies 進行配置管理，為什么目錄結構變了？而不是我們常見的“引用”下面加載所有的程序集，這樣有什么好處？其實我自己覺得一點就是引用更加規范了，我新建的是 ASP.NET 5 類型的項目，那所有的程序集應該都必須適用于此框架下，比如 EntityFramework 7.0 就暫時只適用 ASP.NET 5，新建 AS.NET 5 Class Library 也是如此：

project.json

project.json 是 ASP.NET 5 項目中最最主要的文件，里面包含了此項目的很多配置，有點像我們常使用的 Web.config，project.json 文件是 json 格式，對應架構為：http://json.schemastore.org/project，貼一下示例代碼：

{
    /* Click to learn more about project.json  http://go.microsoft.com/fwlink/?LinkID=517074 */
    "webroot": "wwwroot",
    "version": "1.0.0-*",
    "dependencies": {
        "ClassLibrary1": "",
        "EntityFramework.SqlServer": "7.0.0-beta1",
        "EntityFramework.Commands": "7.0.0-beta1",
        "Microsoft.AspNet.Mvc": "6.0.0-beta1",
        //"Microsoft.AspNet.Mvc.WebApiCompatShim": "6.0.0-beta1",
        "Microsoft.AspNet.Diagnostics": "1.0.0-beta1",
        "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta1",
        "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta1",
        "Microsoft.AspNet.Security.Cookies": "1.0.0-beta1",
        "Microsoft.AspNet.Server.IIS": "1.0.0-beta1",
        "Microsoft.AspNet.Server.WebListener": "1.0.0-beta1",
        "Microsoft.AspNet.StaticFiles": "1.0.0-beta1",
        "Microsoft.Framework.ConfigurationModel.Json": "1.0.0-beta1",
        "Microsoft.Framework.CodeGenerators.Mvc": "1.0.0-beta1",
        "Microsoft.Framework.Logging": "1.0.0-beta1",
        "Microsoft.Framework.Logging.Console": "1.0.0-beta1",
        "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta1"
    },
    "commands": {
        /* Change the port number when you are self hosting this application */
        "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000",
        "gen": "Microsoft.Framework.CodeGeneration",
        "ef":  "EntityFramework.Commands"
    },
    "frameworks": {
        "aspnet50": { },
        "aspnetcore50": { }
    },
    "exclude": [
        "wwwroot",
        "node_modules",
        "bower_components"
    ],
    "packExclude": [
        "node_modules",
        "bower_components",
        "**.kproj",
        "**.user",
        "**.vspscc"
    ],
    "scripts": {
        "postrestore": [ "npm install" ],
        "prepare": [ "grunt bower:install" ]
    }
}

project.json 文件中，我們最常配置的應該是 dependencies 和 commands，commands 配置和我之前在 MAC OS 中使用 Sublime Text 開發 ASP.NET vNext 差不多，可以通過 server.urls 自定義 URL，就像我們使用 IIS 進行站點域名綁定一樣，dependencies 下是所有程序集的引用管理，而且都是通過 Nuget 進行加載的，這部分就沒什么說的了，很多資料都提到過，另外，在 dependencies 配置中添加程序集，VS2015 提供了非常強大的智能感知功能，還可以提示此程序集的版本號，非常酷！

需要注意的是，你會發現，現在 ASP.NET 5 項目所涉及到的程序集都是以“Microsoft”開頭，而不是之前最常見的“System”，而且版本號大部分為“1.0.0-beta1”，雖然現在 VS2015 是預覽版本，所涉及到的程序集為“Beta”也沒什么問題，但“1.0.0”的版本命名確實有些味道在里面，我記得在之前無意間看到一篇博文，講到現在 ASP.NET 5 所設計到的 Framework 更新問題，大致意思是現在的版本都是“全新的”，并沒有在之前的版本中進行“擴充”，然后其中說明了之前 Framework 版本的一大堆問題，很遺憾，我只是大致記得，具體是哪篇博文記不得了。

其他文件

Controllers、Models 和 Views 和我們之前開發的 ASP.NET MVC 項目沒什么區別，Migrations 是示例項目中使用 EntityFramework 代碼遷移文件，Startup.cs 和 OWIN 項目一樣為項目啟動配置，和以前的 global.cs 類似。

前端管理工具

在 VS2015 中，微軟添加了外部前端管理工具，這在以前的 VS 版本中從來沒有，而且這些對我來說都是新東西，首先需要了解幾個關鍵詞：

  • NPM
  • Bower
  • Grunt

如果你也不了解他們，可以從下面幾篇博文進行學習：

說一下我自己對這些的理解，Bower 可以看作是“原材料提供商”，NPM 可以看作是“工具的提供商”，Grunt 可以看作是“具體的工具”，什么意思呢？一個“產品”的產生需要工具對原材料的加工處理，選用什么原材料，Bower 說了算（通過 bower.json 進行配置管理），然后 NPM 提供對這些原材料加工的工具（通過 package.json 進行配置管理），比如 Grunt，最后加工出成型的產品（通過 gruntfile.js 進行配置管理），這里面說的“加工”，其實就是發布管理。

另外，在 VS2015 中，提供了一個 Task Runner Explorer 管理窗口，它主要的作用為 NPM 提供的工具，進行“可視化”的管理（比如 Grunt）：

無編譯開發

無編譯開發指的是，使用 VS2015 開發 ASP.NET 5 項目，修改代碼文件，無需重新編譯生成，只需要保存并刷新瀏覽器即可，一張圖說明：

Microsoft Git Provider

Microsoft Git Provider 是 VS2015 提供的默認代碼管理工具，我們之前在其他的 VS 版本中，如果代碼托管使用的是 Git，我們一般會在 VS 中安裝一個叫“Git Source Control Provider”的擴展插件，但在 VS2015 中內置了一個 Git 插件，而且非常強大，真是不用不知道，一用嚇一跳。

是不是非常酷呢？我覺得酷炫極了，你可以從這張示意圖中得到很多的 Git 信息，每個方法名上面都有一個最后提交的作者信息，還有更新時間顯示，點擊這個提示之后，會有一個圖表顯示更新者的更新點，再點擊會有這次更新點的具體信息。。。

VS2015 中的這個功能，總之一句話“碉堡了”。

智能感知和錯誤信息

VS2015 中的智能感知功能，主要表現在其代碼實現是否包含在某一框架中，如下圖：

關于錯誤信息的描述，看了 MSDN 中的一篇博文，感覺不是很明白，大致意思是錯誤信息可以顯示不同框架的實現，這個不同框架指的是 References 中的 ASP.NET 5.0 和 ASP.NET Core 5.0，其實我也并不是很明白這兩個框架的具體作用，以后在使用的時候再進行探究吧。

另外，還有一個功能是如果出現錯誤，VS2015 會“告知”你：代碼應該怎么寫？

Smart Unit Testing

Smart Unit Testing 原名為 PEX，據說來自微軟研究院的技術，有關介紹：Generate smart unit tests for your code。

在 VS2015 中，整合了 Smart Unit Testing，使得我們進行單元測試變得異常簡單，你只需要在你需要測試的方法中“右擊”，然后點擊“Smart Unit Testing”：

Smart Unit Testing 窗口：

在我們進行這項操作的時候，需要注意的是，并沒有新建 Unit Test 的單元測試項目，而只是單純的使用 VS2015 進行單元測試，也就是說單元測試代碼我們并沒有進行編寫，直接使用測試工具對源代碼進行測試，這種方式和我們使用傳統的 XUnit 測試有所區別，當然有好處也有壞處，取舍問題，適合就好。

Visual Studio 2015 開發 ASP.NET 5 有何變化？現在來說只是皮毛，也就是說是一些表面的東西，真正去理解并使用它，只有通過實際項目的應用，目前來說，Visual Studio 2015 開發 ASP.NET 5 并不是那么簡單，需要學習的東西還有很多，這篇博文希望可以給你帶來一些幫助。

參考資料：


文章列表



Avast logo

Avast 防毒軟體已檢查此封電子郵件的病毒。
www.avast.com


arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()

    E-mail轉寄