上面我们创建的项目是个应用程序，当我们回到类库的时候，在依赖项里会发现一个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）而无需重新发布新的变化。

关于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.lock.json

Project.lock.json 存储编译所需文件的列表（通常为 NuGet 引用）。与 project.json 文件不同，它包括特定的包版本号，可支持通配符。如果没有 project.lock.json，将完整还原包。Project.lock.json 包括包图片以及本地下载的其他与包相关的数据（已还原）。它的工作方式 和 npm以及 RubyGems非常相似，你可以把这个文件签入版本库，也可以不签入，但此文件不存在时，将运行 NuGet restore 还原以重新创建。此文件列为 Visual Studio 中 project.json 的子项。

HellodotnetCore.xproj <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="14.0" DefaultTargets="Build" xmlns=" > <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 成功找到源代码，它会自动将项目添加到你的解决方案，使你可以调试到源代码。