.NET Core系列 ： 1、.NET Core 環境搭建和命令列CLI入門 介紹了.NET Core環境，本文介紹.NET Core中最重要的一個配置檔案project.json的相關內容。我們可以使用.NET Core 的dotnet 命令列介面（CLI）dotnet new命令建立一個應用，也可以用Visual Studio 2015 update 3建立一個應用，他們都有一個project.json ，它是專案的配置檔案，類似之前的*.csrpoj檔案。Project.json 是一個新的專案檔案，它的功能大部分與 *.*PROJ 檔案重疊。它可標識專案引用、版本選項（如版本號）等事項，並可標識要編譯的平臺，例如，是 .NET Core 還是 .NET Framework。心細的你可能已經發現了他們所創建出來的project.json 檔案的內容有很多都不一樣。我們下面就來看下這個檔案的內容，project.json 的官方文件

https://docs.microsoft.com/en-us/dotnet/articles/core/tools/project-json 。

project.json

首先，從我們 通過 Visual Studio 建立的專案 xproj  的 project.json︰

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
    }
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

dotnet new 命令建立專案的 project.json:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "type": "platform",
          "version": "1.0.0"
        }
      },
      "imports": "dnxcore50"
    }
  }
}

他們結構上看是相似的，但是具體內容上有很大的不同的地方，他們都有4個頂級的屬性：version, buildOptions, dependencies 和 framework。.NET Core 專案結構中最重要的檔案可能是 project.json。此檔案旨在：

替換 NuGet 檔案管理器 package.config 檔案，它可標識專案的 NuGet 引用。
指定專案支援的框架，以及有關如何為特定框架構建專案的配置詳細資訊。
標識獨立應用的目標平臺，它含有其所有依賴項，包括對應平臺所需的特定於平臺的 .NET Core 執行時。或者，如果專案是可移植應用，project.json 可標識專案會在目標計算機（將在其上執行程式集）上安裝的框架。
這三個任務分佈在 project.json 中的四個主要部分（根據專案型別，我將Frameworks 和 dependencies合併為功能重疊）：

Version

version 這個屬性是你所要構建的元件的最小的元資料，其他元資料包括name,title，description ，copyright 等， name 選項預設情況下使用的是父資料夾名稱，你可以通過name 這個屬性給它取個你想要的名字。

buildOptions

buildOptions節點定義瞭如何編譯和編譯哪些檔案等，也就是編譯選項。編譯選項部分包含一些有用的屬性。首先是 emitEntryPoint，這用來確定是否生成可執行二進位制檔案或 exe 。預設情況下，呼叫 Program.Main() 方法將被呼叫來執行你的應用。

我發現一個有趣的屬性是"debugType":"portable"。Visual Studio 程式碼偵錯程式必須設定這個屬性才能夠工作的。但這也意味著您的應用程式將以不同的方式釋出，具體哪個值取決於您在此處的設定。簡要的可以看前一篇文章的dotnet publish 節，更多的介紹在後面釋出應用程式的時候介紹。

Frameworks 和 dependencies

dependencies此部分列出了你的專案所依賴的各個 NuGet 包，包括所述依賴項的版本號。可以使用萬用字元指定版本號，從而你可以允許 NuGet 包管理器還原自動下載與萬用字元相匹配的“最新版本”。版本號的空引號對錶示“使用最新可用項”。我們建立的專案可以針對一個或者多個Framework（比如我們希望建立的可以同時在.NET Framework和.NET Core上執行），支援的Framework定義在frameworks節點下。如果添加了多個Framework，並不是說最終生成的應用可以同時在這 些Framework中執行，而是說原始檔在編譯的時候會針對這些Framework生成對應的程式集。對於傳統的.NET專案來說，如果我們需要呼叫某個API，需要新增所在程式集的引用。對於.NET Core來說，所有使用到的程式集都被打包成一個NuGet包，所以針對程式集的直接依賴轉變成針對某個NuGet包的依賴。針對NuGet的依賴主要有 兩種型別，一種是針對所有Framework的，它們會直接定義在dependencies節點下，另一種則是針對某個具體Framework的， 定義為當前Framework節點下的dependencies子節點。對於獨立應用，執行時部分指定將支援的 OS，因此可指定要繫結到應用程式的執行時庫。

從上面2個project.json 檔案可以看出Frameworks 和 dependencies 存在依賴關係。他們是可以巢狀的，在最高一級的依賴項，將是所有的Frameworks所依賴的，也可以針對一個具體的Framework 構建它的依賴關係，不同的Framework使用不同版本的依賴項。看上面的例子，我們看到Visual Studio和dotnet CLI版本定義的是相同的結果，只是兩種不同的表達方式。

Microsoft.NETCore.App

我們來仔細看下 Microsoft.NETCore.App:

"Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
   }

這是一個依賴項，平臺的依賴，它也是Nuget包，其中包含了一堆系統庫的NuGet程式包，包含.netcore的基礎執行時和基礎類庫。 文章 

netcoreapp1.0

我們再來仔細看下  netcoreapp1.0:

"frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }

框架netcoreapp1.0 是個多目標框架物件名字（TFM）值，除了有經典的net45，net46，現在又有了一些新的像netcoreapp1.0,文章 

NETStandard.Library

上面我們建立的專案是個應用程式，當我們回到類庫的時候，在依賴項裡會發現一個NETStandard.Library：

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable"
  },
  "dependencies": {},
  "frameworks": {
    "netstandard1.6": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    }
  }
}

這也是一個NuGet 程式包： https://www.nuget.org/packages/NETStandard.Library/，裡面包含了多個目標版本，類似於老的PCL方法，以後就使用NETStandard.Library替代了PCL，我們有了一個更加統一的版本控制策略。

本質上來說，NETStandard.Library 是一個目標最低支援基礎類庫，這樣就可以更好的向前相容性，在現有的平臺出現新的版本時（如.net core 1.1 甚至 2.0）而無需重新發布新的變化。具體參考 https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md ，目前最新的表格：

如何理解這個表格

• 如果一個類庫指定.NET平臺標準1.3版本，那麼它僅能夠執行在.NET Framework 4.6或更新的框架、Universal Windows Platform 10（UWP）、DNX Core 5.0和Mono/Xamarin這些平臺上。
• 如果一個類庫指定.NET平臺標準1.3版本，那麼它能夠引用（原文：consume）所有來自之前的.NET平臺標準的版本（1.2、1.1、1.0）。

關於project.json 的更多資訊

.NET Core專案依賴全部使用NuGet，要求使用NuGet 3.0版本，預設使用nuget.org 作為源。在安裝VS2015 Update3時，.NET Core所需的官方依賴包都已經安裝在了（預設安裝）C:\Program Files (x86)\Microsoft SDKs\NuGetPackages目錄下，在nuget管理中也可以看到這是預設的離線包目錄，我們需要什麼樣的包只要把它複製到這個目錄，在nuget管理中的程式包源選擇離線的源即可。執行dotnet restore命令後項目會根據project.json檔案配置來恢復專案依賴包，同時就會生成新的project.json.lock檔案。

project.json.lock 

Project.json.lock 儲存編譯所需檔案的列表（通常為 NuGet 引用）。與 project.json 檔案不同，它包括特定的包版本號，可支援萬用字元。如果沒有 project.json.lock，將完整還原包。Project.json.lock 包括包圖片以及本地下載的其他與包相關的資料（已還原）。它的工作方式 和 npm以及 RubyGems非常相似，你可以把這個檔案簽入版本庫，也可以不簽入，但此檔案不存在時，將執行 NuGet restore 還原以重新建立。此檔案列為 Visual Studio 中 project.json 的子項。

HellodotnetCore.xproj

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>

  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.Props" Condition="'$(VSToolsPath)' != ''" />
  <PropertyGroup Label="Globals">
    <ProjectGuid>34ee435f-9fda-4fb2-b4fb-a3203939f0c5</ProjectGuid>
    <RootNamespace>HellodotnetCore</RootNamespace>
    <BaseIntermediateOutputPath Condition="'$(BaseIntermediateOutputPath)'=='' ">.\obj</BaseIntermediateOutputPath>
    <OutputPath Condition="'$(OutputPath)'=='' ">.\bin\</OutputPath>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
  </PropertyGroup>

  <PropertyGroup>
    <SchemaVersion>2.0</SchemaVersion>
  </PropertyGroup>
  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.targets" Condition="'$(VSToolsPath)' != ''" />
</Project>

和以往的csproj 檔案一樣，這個檔案架起Visual Studio 和MSBuild溝通的橋樑。HellodotnetCore.xproj 定義構建專案時將發生的事項。最新版本可匯入 Microsoft.DotNet.targets，它定義了利用新 DotNet.exe 命令的構建任務。與過去的 MSBuild proj 檔案不同，xproj 檔案非常小，因為大部分資訊已（暫時）移到 project.json。不過後續這個檔案要被csproj 替代，也許就在不久的將來的Visual Studio 2016上面就變成了csproj。

global.json

global.json是一個有待探究的神奇配置檔案，我最喜歡的一個功能是全新的支援除錯和單步執行，甚至可以實時修改包的原始碼。假設你有公司範圍的“框架”程式集，可以在眾多團隊之間共享。但是，

但是，框架包實際上是開源的，因此公司內（或者，甚至更好，公司外部）的任何人員均可進行完善和更改。現在，想像你如果為此框架引用 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/geffzhang/documents/visual studio2015/Projects/Microsoft.Extensions.Logging）。

更新並儲存 global.json 後，一旦 Visual Studio 成功找到原始碼，它會自動將專案新增到你的解決方案，使你可以除錯到原始碼。

這裡使用了一種非常棒的演算法來確定要載入的原始碼目錄：

1. 如果 global.json 中指定的任何原始碼位置包含的資料夾具有與包相同的名稱（如 Microsoft.Extensions.Logging），且此資料夾包含名為 project.json 的檔案，除錯程式將使用此資料夾及其內部的原始檔。
2. 否則，會載入包資料夾中編譯的二進位制程式。

本文簡要介紹了.NET Core專案中最為重要的一個配置檔案project.json的內容和相關的工具，類庫等基礎資訊，下篇文章我們來聊聊如何構建多個Project的解決方案的內容。