.NET Core - 解决方案、框架、导入、运行时
.NET Core - solutions, frameworks, imports, runtimes
我正在开始重新设计一组框架库以使用 .NET Core。以为我会等待 RC2 并热衷于陷入困境。
我借此机会近距离接触构建系统、配置、从头开始编写所有代码以加深理解，并且没有我没有的不必要的包袱 want/need。然而，缺乏文档使这变得非常困难。所以我想在这里问一下，聪明的 .NET Core 人员无疑藏在哪里 ;)
我知道这个问题很长而且有很多子问题。但我觉得可以通过单个 link 文档或知情人士的几句话来回答。感谢您的耐心等待，我希望这可能成为对同一条船上的其他人有用的答案资源，试图了解 .NET Core 的好方法。
首先，global.json。我想要同一个 'solution' 中的多个项目和组件。通过另一个 SO 问题，我发现这个隐藏的 link: http://dotnet.github.io/docs/project-model/global-json-reference.html - 但似乎没有用于从头开始设置或使用它的 VS 工具。
1) global.json 个问题
A) 这些文档指的是什么构建系统？ dotnet build？ （帮助说它只是建立一个项目 - 如果它确实 'solutions' - 如果那仍然是名称 - 它只是 运行 dotnet build 所有子文件夹吗？）。
B) 许多示例都有 "sdk" 属性 - 但 EF Core 没有它，新的 "single-sentence-style" 文档也没有引用它。 The official RC2 migration guide for ASP.NET Core has it它还在不在？如果是这样，为什么需要它？它有什么用？它有哪些选项？
接下来是 project.json 和框架。我想了解此处的框架选项。有名单吗？官方指导？ dotnet new 使用 netcoreapp1.0； "official docs" use an example of dnxcore50 and this GH discussion from last month 还提出了 netcore1.0 作为框架（与应用程序）的可能性的问题。
此外，imports。我对命名感到非常困惑 - 文档谈到这是该项目兼容的其他框架的列表..
2) project.json 框架问题 -
A) 我在哪里可以找到关于框架选项的最新或维护列表或建议集？
B) 如果我对import目的的理解是正确的，那为什么要这样命名呢？如果不是，它究竟导入了什么？
C) 为什么每个 framework 属性 都有一个 import 属性？如果是为了表明整个项目与另一个框架兼容，那似乎最好放在project.json的顶层，不是吗？
D) 我应该如何决定我应该使用哪些 import 选项？ dotnet new 刚刚 dnxcore50 - 满足哪些软件包？ This guy 建议 dotnet5.6、dnxcore50 和 portable-net45+win8!
最后，我正在构建 class 库、测试项目、控制台实用程序。所以..
3) 参考和包
A) 我总是希望 Microsoft.NETCore.App 符合 dotnet new 吗？还有其他基准选项吗？选择指导？列表？
B) 文档没有提及任何关于 type 选项（build、platform）的内容。有关于这些的指导吗？
C) 我的一些项目将使用 ASP.NET。在哪里可以找到正确的包以供参考？ NuGet 上似乎有一百万个版本和包。 This tutorial 只是谈论引用 Microsoft.AspNetCore.Server.Kestrel - 唯一 ASP.NET 引用的东西是 Microsoft.AspNetCore.Hosting。这是否意味着一个包裹是 ASP.NET 的大部分？
你有很多问题。没有单独的文档，因为问题不是那么简单；)
global.json
- global.json 构建系统：global.json（如 project.json）不指定构建系统（除了例如 msbuild csproj 文件）。目前，只有
dotnet build 可用（在 VS 中使用时由 msbuild xproj 代理）。这将更改为 msbuild，因为完整的工具在 preview/beta 中并且不会在 6 月底发布。它遍历所有子文件夹并构建这些东西。也是查找本地项目引用的根节点。
- global.json sdk: 即构建时使用的sdk。新的cli也支持多sdk，我觉得这个还是用来选的
project.json
- project.json 框架列表：我建议您阅读 platform standard document and there you find a list of current framework monikers. This document will also resolve many other questions you (might) have. A complete list is in the NuGet project docs，但该列表再次被弃用，也不是很有用。您的示例
netcore 引用用于 UWP（运行时也称为 .NET Core），而跨平台 .NET Core 使用 netcoreapp，这在 NuGet 文档中完全缺失。
- project.json import: 你理解错了。在 project.json 中，您指定构建库实现的目标框架（例如
netstandard1.6 和 net451）。 import 语句用于您为目标框架指定的依赖项，基本上表示：如果 TFM（例如 netstandard1.6）在引用的库中不存在（因为 NuGet 是前一段时间构建的），我也接受这些导入一次（例如已弃用的 dotnet5.6 或 dnxcore50）。这是目前用于破坏 NuGet 并允许使用尚未移至新 TFM 的库的实用程序。它不会说明您的项目，而是说明您接受使用哪些版本的依赖项。这需要为每个目标框架单独规范，因为每个目标框架对 NuGet 库实现的接受可能不同。
- project.json import usage: 嗯，需要的就用，不需要的就去掉。当您将尚未迁移到新 TFM 的 NuGet 引用时，您将收到错误消息。
dnxcore 和 dotnet 是对 .NET Core 项目的节省赌注，因为它们在当前名字 netstandard 和 netcoreapp 被创造之前就已被使用。只是不要那么大胆地添加例如基于 net461/mscorlib 的 NuGet 实现到基于 netstandard/System.Runtime 的目标框架。这是行不通的，是一个常见的错误。
依赖关系
- dotnet 新默认模板：是的，对于 ASP.NET 和始终是正确选择的控制台应用程序。然而，这只是一个简单的控制台应用程序（网络应用程序也是控制台应用程序）。使用 Visual Studio 创建新的 ASP.NET 核心项目或在 Linux 下使用 yeoman 进行高级模板化。
dotnet new 不是一个完整的脚手架系统。新模板使用 netcoreapp 目标框架和 Microsoft.NETCore.App 元包来导入基本上所有可用的基础 class 库。如果你想创建一个库，切换到 netstandard 目标框架并依赖于 NETStandard.Library。您仍然可以添加其他依赖项。对于 ASP.NET 核心，没有可用的直接元数据包。指导到此结束。有一个称为修剪的过程，您可以在其中删除这些元包并添加具体的依赖项。但目前还没有工具。
- project.json build/platform dependencies:
build dependencies本质上是工具，在构建过程中不会发布。当你知道 npm 时，你就知道这个方案是 devDependencies。 platform dependencies 本质上是一个依赖项，它不与您的应用程序一起部署，而是作为 .NET Core SDK 的共享基础安装的一部分。您在 "portable application"（即 platform）和 "self-contained application"（即没有）项下找到 guidance。
- project.json 元包/传递依赖：.NET Core 和 project.json 引入了元包的概念。
Microsoft.NETCore.App 本质上是 .NET Core 命令行应用程序的基线依赖项，NETStandard.Library 是 class 库的基线依赖项。所有这些包都可以有自己的代码和其他包的传递依赖。这些你也可以使用。例如，Microsoft.NETCore.App 包引用 NETStandard.Library，它再次引用 System.Collections.Generic。因此，在您引用 Microsoft.NETCore.App 的应用中，您可以使用通用集合。 ASP.NET Core 情况不同，因为现收现付的理念对性能非常关键。对于高效的应用程序，您必须了解您添加的内容。作为初学者，您必须使用像 VS 或 yeoman 这样的脚手架系统。 Microsoft.AspNetCore.Server.Kestrel（例如纯文本）或 Microsoft.AspNetCore.Mvc（对于网络 api）可传递地包含大多数其他关键 ASP.NET 核心依赖项。
免责声明：上面的大部分主题都与被认为是 "preview" 的工具相关。 "preview" 表示 "beta"。即将发生重大变化（例如将构建系统从 project.json 切换回 msbuild，或再次改进 .NET 标准）。
我希望这能回答您的大部分问题。我认为在一个问题中回答所有问题是一项挑战 ;)。
我正在开始重新设计一组框架库以使用 .NET Core。以为我会等待 RC2 并热衷于陷入困境。
我借此机会近距离接触构建系统、配置、从头开始编写所有代码以加深理解，并且没有我没有的不必要的包袱 want/need。然而，缺乏文档使这变得非常困难。所以我想在这里问一下，聪明的 .NET Core 人员无疑藏在哪里 ;)
我知道这个问题很长而且有很多子问题。但我觉得可以通过单个 link 文档或知情人士的几句话来回答。感谢您的耐心等待，我希望这可能成为对同一条船上的其他人有用的答案资源，试图了解 .NET Core 的好方法。
首先，global.json。我想要同一个 'solution' 中的多个项目和组件。通过另一个 SO 问题，我发现这个隐藏的 link: http://dotnet.github.io/docs/project-model/global-json-reference.html - 但似乎没有用于从头开始设置或使用它的 VS 工具。
1) global.json 个问题
A) 这些文档指的是什么构建系统？ dotnet build？ （帮助说它只是建立一个项目 - 如果它确实 'solutions' - 如果那仍然是名称 - 它只是 运行 dotnet build 所有子文件夹吗？）。
B) 许多示例都有 "sdk" 属性 - 但 EF Core 没有它，新的 "single-sentence-style" 文档也没有引用它。 The official RC2 migration guide for ASP.NET Core has it它还在不在？如果是这样，为什么需要它？它有什么用？它有哪些选项？
接下来是 project.json 和框架。我想了解此处的框架选项。有名单吗？官方指导？ dotnet new 使用 netcoreapp1.0； "official docs" use an example of dnxcore50 and this GH discussion from last month 还提出了 netcore1.0 作为框架（与应用程序）的可能性的问题。
此外，imports。我对命名感到非常困惑 - 文档谈到这是该项目兼容的其他框架的列表..
2) project.json 框架问题 -
A) 我在哪里可以找到关于框架选项的最新或维护列表或建议集？
B) 如果我对import目的的理解是正确的，那为什么要这样命名呢？如果不是，它究竟导入了什么？
C) 为什么每个 framework 属性 都有一个 import 属性？如果是为了表明整个项目与另一个框架兼容，那似乎最好放在project.json的顶层，不是吗？
D) 我应该如何决定我应该使用哪些 import 选项？ dotnet new 刚刚 dnxcore50 - 满足哪些软件包？ This guy 建议 dotnet5.6、dnxcore50 和 portable-net45+win8!
最后，我正在构建 class 库、测试项目、控制台实用程序。所以..
3) 参考和包
A) 我总是希望 Microsoft.NETCore.App 符合 dotnet new 吗？还有其他基准选项吗？选择指导？列表？
B) 文档没有提及任何关于 type 选项（build、platform）的内容。有关于这些的指导吗？
C) 我的一些项目将使用 ASP.NET。在哪里可以找到正确的包以供参考？ NuGet 上似乎有一百万个版本和包。 This tutorial 只是谈论引用 Microsoft.AspNetCore.Server.Kestrel - 唯一 ASP.NET 引用的东西是 Microsoft.AspNetCore.Hosting。这是否意味着一个包裹是 ASP.NET 的大部分？
你有很多问题。没有单独的文档，因为问题不是那么简单；)
global.json
- global.json 构建系统：global.json（如 project.json）不指定构建系统（除了例如 msbuild csproj 文件）。目前，只有
dotnet build可用（在 VS 中使用时由 msbuild xproj 代理）。这将更改为msbuild，因为完整的工具在 preview/beta 中并且不会在 6 月底发布。它遍历所有子文件夹并构建这些东西。也是查找本地项目引用的根节点。 - global.json sdk: 即构建时使用的sdk。新的cli也支持多sdk，我觉得这个还是用来选的
project.json
- project.json 框架列表：我建议您阅读 platform standard document and there you find a list of current framework monikers. This document will also resolve many other questions you (might) have. A complete list is in the NuGet project docs，但该列表再次被弃用，也不是很有用。您的示例
netcore引用用于 UWP（运行时也称为 .NET Core），而跨平台.NET Core使用netcoreapp，这在 NuGet 文档中完全缺失。 - project.json import: 你理解错了。在 project.json 中，您指定构建库实现的目标框架（例如
netstandard1.6和net451）。import语句用于您为目标框架指定的依赖项，基本上表示：如果 TFM（例如netstandard1.6）在引用的库中不存在（因为 NuGet 是前一段时间构建的），我也接受这些导入一次（例如已弃用的dotnet5.6或dnxcore50）。这是目前用于破坏 NuGet 并允许使用尚未移至新 TFM 的库的实用程序。它不会说明您的项目，而是说明您接受使用哪些版本的依赖项。这需要为每个目标框架单独规范，因为每个目标框架对 NuGet 库实现的接受可能不同。 - project.json import usage: 嗯，需要的就用，不需要的就去掉。当您将尚未迁移到新 TFM 的 NuGet 引用时，您将收到错误消息。
dnxcore和dotnet是对 .NET Core 项目的节省赌注，因为它们在当前名字netstandard和netcoreapp被创造之前就已被使用。只是不要那么大胆地添加例如基于net461/mscorlib 的 NuGet 实现到基于netstandard/System.Runtime 的目标框架。这是行不通的，是一个常见的错误。
依赖关系
- dotnet 新默认模板：是的，对于 ASP.NET 和始终是正确选择的控制台应用程序。然而，这只是一个简单的控制台应用程序（网络应用程序也是控制台应用程序）。使用 Visual Studio 创建新的 ASP.NET 核心项目或在 Linux 下使用 yeoman 进行高级模板化。
dotnet new不是一个完整的脚手架系统。新模板使用netcoreapp目标框架和Microsoft.NETCore.App元包来导入基本上所有可用的基础 class 库。如果你想创建一个库，切换到netstandard目标框架并依赖于NETStandard.Library。您仍然可以添加其他依赖项。对于 ASP.NET 核心，没有可用的直接元数据包。指导到此结束。有一个称为修剪的过程，您可以在其中删除这些元包并添加具体的依赖项。但目前还没有工具。 - project.json build/platform dependencies:
builddependencies本质上是工具，在构建过程中不会发布。当你知道npm时，你就知道这个方案是devDependencies。platformdependencies 本质上是一个依赖项，它不与您的应用程序一起部署，而是作为 .NET Core SDK 的共享基础安装的一部分。您在 "portable application"（即platform）和 "self-contained application"（即没有）项下找到 guidance。 - project.json 元包/传递依赖：.NET Core 和 project.json 引入了元包的概念。
Microsoft.NETCore.App本质上是 .NET Core 命令行应用程序的基线依赖项，NETStandard.Library是 class 库的基线依赖项。所有这些包都可以有自己的代码和其他包的传递依赖。这些你也可以使用。例如，Microsoft.NETCore.App包引用NETStandard.Library，它再次引用System.Collections.Generic。因此，在您引用Microsoft.NETCore.App的应用中，您可以使用通用集合。 ASP.NET Core 情况不同，因为现收现付的理念对性能非常关键。对于高效的应用程序，您必须了解您添加的内容。作为初学者，您必须使用像 VS 或 yeoman 这样的脚手架系统。Microsoft.AspNetCore.Server.Kestrel（例如纯文本）或Microsoft.AspNetCore.Mvc（对于网络 api）可传递地包含大多数其他关键 ASP.NET 核心依赖项。
免责声明：上面的大部分主题都与被认为是 "preview" 的工具相关。 "preview" 表示 "beta"。即将发生重大变化（例如将构建系统从 project.json 切换回 msbuild，或再次改进 .NET 标准）。
我希望这能回答您的大部分问题。我认为在一个问题中回答所有问题是一项挑战 ;)。