.NET Core 在Visual Studio 2015 下的使用-MSDN

.NET Core RC2 現已推出,這是真正的"候選發佈"而非 RC1 Beta 冒充的候選發佈(若是是那樣,請考慮發佈後出現的全部更改)。當前,圍繞 .NET Core 的開發焦點主要是跨平臺功能。對於支持 Linux 和 Mac OS X 的專一不只提供了新的 .NET API,還附帶提供了運行時甚至工具集。DOTNET.EXE(先前爲 DNX、DNVM 和 DNU)等工具,更沒必要說 Visual Studio Code,使全部非 Microsoft 開發者能夠利用 .NET,甚至能夠享受一流的開發者體驗。 html

開始使用 git

能夠開始利用 .NET Core RC2 以前,你須要更新工具 - 此案例中爲 Visual Studio 2015 - 以支持新的平臺。主要包括兩個步驟: web

下載適用於 Visual Studio 2015 的 .NET Core 工具預覽版 1,下載地址:microsoft.com/net/core#windows(還可從中找到說明)。 算法

從 bit.ly/27Rmeaj 安裝 Nuget 包管理器。 json

假定你已安裝 Visual Studio 2015,但若是未安裝,可從 visualstudio.com 免費獲取 Visual Studio 社區版。 windows

新的項目類型 安全

安裝全部 Visual Studio 工具後,便可使用"新建項目"嚮導建立項目 服務器

如你所見,有四類項目(當同時駐留在 Visual C#\Web 和 Visual C#\.NET Core 文件夾中時,項目會出現兩次)。 架構

顯然,每一個項目類型生成一組不一樣的文件 app

文件名

類庫

控制檯應用程序

ASP.NET Core Web 應用程序 (.NET Core)

ASP.NET Core Web 應用程序 (.NET Framework)

app.config

  

  

  

X

Properties\AssemblyInfo.cs

X

X

  

  

Class1.cs

X

  

  

  

Global.json

X

X

X

X

Properties\launchSettings.json

  

  

X

X

Program.cs

  

X

X

X

Project.json

X

X

X

X

Project.lock.json

X

X

X

X

Project_Readme.html

  

  

X

X

<Project>.xproj

  

  

X

X

<Project>.xproj.user

  

  

X

X

Startup.cs

  

  

X

X

Web.config

  

  

X

X

App.config 是一個可選配置文件,相似於傳統的 <appname>.config,自 .NET Framework 1.0 起便開始使用。如下代碼顯示默認文件,用於標識是使用基於服務器的垃圾回收仍是使用客戶端/工做站類型的垃圾回收(參見 bit.ly/22nm32o 瞭解更多信息):

<configuration>

<runtime>

<gcServer enabled="true"/>

</runtime>

</configuration>

AssemblyInfo.cs 標識程序集數據,如配置、公司、產品和商標。這是標準的 AssemblyInfo.cs 文件,自 2000 年首次發佈 .NET 起便屬於 Visual Studio .NET 項目的一部分。

Class1.cs 是 Class1 類的框架 C# 類文件,包括其默認構造函數。

建立首個 .NET Core 項目時,若是選擇"建立解決方案的目錄",便會自動生成 Global.json。如本文稍後進行的詳細介紹,項目的節點可在調試時標識源代碼的其餘位置。

LaunchSettings.json 標識各類 Web 託管配置設置,包括用於調試的應用程序 URL;任何存在的 IIS 主機(如 IIS Express);啓動、使用前要設置的環境變量,如經過 .NET Core 配置標識環境(開發、測試或生產);SSL 和身份驗證。對 Visual Studio 的項目屬性窗口上"調試"選項卡所作的更改提供了 UI 以編輯 launchSettings.json 文件

如下是一個示例 launchSettings.json 文件

{

"iisSettings": {

"windowsAuthentication": false,

"anonymousAuthentication": true,

"iisExpress": {

"applicationUrl": "http://localhost:43799/",

"sslPort": 0

}

},

"profiles": {

"IIS Express": {

"commandName": "IISExpress",

"launchBrowser": true,

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development"

}

},

"WebApplication1NetFramework": {

"commandName": "Project",

"launchBrowser": true,

"launchUrl": "http://localhost:5000",

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development"

}

}

}

}

Project.json 是一個新的項目文件,它的功能大部分與 *.*PROJ 文件重疊。它可標識項目引用、版本選項(如版本號)等事項,並可標識要編譯的平臺,例如,是 .NET Core 仍是 .NET Framework。稍後將對此進行詳細介紹。

Project.lock.json 存儲編譯所需文件的列表(一般爲 NuGet 引用)。與 project.json 文件不一樣,它包括特定的包版本號,可支持通配符。若是沒有 project.lock.json,將完整還原包。Project.lock.json 包括包圖片以及本地下載的其餘與包相關的數據(已還原)。一般,不會簽入此文件,但此文件不存在時,將運行 NuGet 包還原以從新建立。此文件列爲 Visual Studio 中 project.json 的子項。

ClassLibrary.xproj 是現成的 MSBuild 文件,定義構建項目時將發生的事項。最新版本可導入 Microsoft.DotNet.targets,它定義了利用新 DotNet.exe 命令的構建任務。與過去的 MSBuild proj 文件不一樣,xproj 文件很是小,由於大部分信息已(暫時)移到 project.json。

ClassLibrary.xproj.user 會覆蓋 Class-Library.xproj 文件,並提供其餘 MSBuild 屬性,如本地用戶調試特定設置(如端口)。一般,不會簽入此文件,由於它特定於用戶,且在 Visual Studio 中不可見。

Program.cs 定義項目類,包括定義應用程序(甚至包括 Web 應用程序)的主入口點。

Web.config 提供 IIS 的最低配置,指示在何處查找 Web 主機進程並配置全部通訊將重定向到此進程,如如下代碼所示:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<system.webServer>

<handlers>

<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule"

resourceType="Unspecified"/>

</handlers>

<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%"

stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"

forwardWindowsAuthToken="false"/>

</system.webServer>

</configuration>

請注意,web.config 再也不包含應用設置,此設置將移到經過 Microsoft.Extensions.Configuration 加載的配置文件,請參見我在 2016 年 2 月發佈的文章".NET Core 中的配置"(bit.ly/1OoqmkJ)。

請注意,對於經過 Visual Studio 建立的全部 .NET Core 項目類型,若是在建立新項目時選擇"建立解決方案的目錄"選項,全部源代碼都會放置在解決方案的子目錄中。此外,咱們但願測試項目將放置在 src 旁邊的測試目錄中(儘管在適用於 Visual Studio 2015 版本的 .NET Core 工具預覽版 1 中默認狀況下不會執行此操做)。其餘能夠考慮的目錄有版本和文檔等。(我認可,我更喜歡將個人測試項目隨要測試的目標項目一塊兒放置,而不是放置在徹底獨立的樹中,可是默認狀況下 Microsoft 不會爲解決方案結構選擇此操做,根據經驗,咱們應儘量使用默認設置,而非嘗試與默認設置相對立。)

有關 Project.json 的更多信息

.NET Core 項目結構中最重要的文件多是 project.json。此文件旨在:

替換 NuGet 文件管理器 package.config 文件,它可標識項目的 NuGet 引用。

指定項目支持的框架,以及有關如何爲特定框架構建項目的配置詳細信息。

標識獨立應用的目標平臺,它含有其全部依賴項,包括對應平臺所需的特定於平臺的 .NET Core 運行時。或者,若是項目是可移植應用,project.json 可標識項目會在目標計算機(將在其上運行程序集)上安裝的框架。

這三個任務分佈在 project.json 中的四個主要部分(根據項目類型,我將運行時和支持合併爲功能重疊):

依賴關係: 此部分列出了你的項目所依賴的各個 NuGet 包,包括所述依賴項的版本號。可使用通配符指定版本號,從而你能夠容許 NuGet 包管理器還原自動下載與通配符相匹配的"最新版本"。版本號的空引號對錶示"使用最新可用項"。 此外,不只能夠經過 Visual Studio NuGet 包管理器窗口添加引用,還能夠依賴於 Visual Studio 利用已配置包源中可用的包異步加載 IntelliSense 的方式(參見圖 )。IntelliSense 適用於包名稱和版本號。

框架: 在此部分中,你可識別項目將運行的框架:如 net4五、netstandard1.五、net40。此外,你能夠提供版本選項、依賴項、框架程序集並將特定應用導入已標識的框架。例如,要容許將不安全代碼用於 .NET 45 執行環境,能夠在框架元素中進行指定:

"net45": {"buildOptions": {"allowUnsafe": true}}

運行時/支持:project.json 是使用運行時仍是使用支持取決於項目是針對可移植應用仍是獨立應用。對於獨立應用,運行時部分指定將支持的 OS,所以可指定要綁定到應用程序的運行時庫。在目標計算機上預安裝的任何項目上,獨立應用程序沒有依賴項(至少 .NET 如此)。

相反,支持部分爲可移植應用標識啓動時應用將查找的運行時依賴項 - 具備其中任何一個即足夠。此列表不受限(你能夠在任意位置運行),但 supports 元素將致使 NuGet 檢查是否全部依賴項均知足。

project.json 在 RC1 和 RC2 中相當重要,但諷刺地是,RC2 發佈不久以後,.NET Core 和 ASP.NET 團隊肯定 project.json 實際上對已良好創建的 MSBuild 項目文件而言是多餘的,它已支持很是多的功能,包括配置、生成依賴項、生成目標、編譯標記、命令行和環境變量屬性設置以及構建命令。團隊沒有對其進行完全改造,而是查看是什麼首先觸發了 project.json 文件生成,並意識到 *.*PROJ 文件一般很是大(如,在項目中單獨列出了各個文件),而非使用通配模式(通配符)。實際上文件很是大,開發者不多在運行版本以前打開並查看此文件,即便此文件可能會將一些不須要的命令嵌入其中。團隊沒有建立全新的生成文件,而是決定修復 *.*PROJ 文件內的膨脹問題,而且甚至提供了命令行實用程序以對其進行編輯。project.json 有而 *.*PROJ 文件沒有的惟一一項是 JSON 語法。(可是,畢竟 JSON 只是現代的 XML,如同 XML [在它的時代]也曾是現代的 flat 或 INI 文件同樣。) 有關 project.json 潛在消亡的詳細信息,請參閱:2016 年 5 月 10 日 Damian Edwards 在 ASP.NET Community Standup 中發佈的公告、Alexandre Mutel (bit.ly/1NJ9r31) 發佈的相應帖子以及 Willem Meints 在博客 (bit.ly/1sJc2An) 上發佈的摘要。

調試包源代碼

我最喜歡的一個功能是全新支持調試和單步執行包,甚至能夠適時修改包的源代碼。假設你有公司範圍內的"框架"程序集,可在衆多團隊之間共享。可是,框架包其實是開源的,所以公司內(或者,甚至更好,公司外部)的任何人員都可進行完善和更改。如今,想像你若是爲此框架引用 NuGet 包,但有時懷疑可能存在須要修復的缺陷或可能存在一個批准的加強功能。一般,這須要獨立於項目/解決方案處理組件中的源代碼。相反,若是你可以下載源代碼並隨主開發將其更新爲集成式體驗 - 甚至單步執行代理,而不依賴於符號服務器或 PDB 文件是否可用,會怎麼樣? 幸運地是,Visual Studio 2015 支持此關鍵場景。

例如,想象你想要調試 GitHub 上可用的 Microsoft.Extensions.Logging 包。要在項目中對其進行添加和調試,你須要下載(可能使用 git clone 或 git submodule 命令)源代碼。接下來,爲了使 Visual Studio 知曉在何處查找源代碼,你須要編輯 global.json 項目節點,如將"submodules\Logging"添加到查看的目錄列表:

{

"projects": [ "src", "test", "submodules\Logging" ],

"sdk": {

"version": "1.0.0-*"

}

}

固然,你能夠提供完整路徑(例如,你未將代碼克隆到子目錄)。可是,請注意,目錄分隔符是兩個反斜槓 (\\) 或單個正斜線(如 c:/users/mark/documents/visual studio2015/Projects/Microsoft.Extensions.Logging)。

更新並保存 global.json 後,一旦 Visual Studio 成功找到源代碼,它會自動將項目添加到你的解決方案,使你能夠調試到源代碼。

這裏使用了一種很是天真的算法來肯定要加載的源代碼目錄:

若是 global.json 中指定的任何源代碼位置包含的文件夾具備與包相同的名稱(如 Microsoft.Extensions.Logging),且此文件夾包含名爲 project.json 的文件,調試程序將使用此文件夾及其內部的源文件。

不然,會加載包文件夾中編譯的二進制程序。

有關詳細信息,請參閱"使用 Visual Studio 2015 調試 ASP.NET 5 Framework 代碼"(bit.ly/22niJ7w)。

總結

若是你還沒有開始深刻了解 .NET Core,如今是絕佳時機,你能夠獲取最長時間跨度以在其中分攤學習曲線。這對考慮升級早期版本的用戶一樣適用。機不可失,請儘早升級,越早升級,越能夠儘早利用其新功能。

相關文章
相關標籤/搜索