.NET Core - 解决方案，框架，导入，运行时

Question

我开始重新编写一组框架库以使用.NET Core。我以为我等待RC2并且热衷于陷入其中。

我借此机会与构建系统亲密接触，配置，从头开始编码，以获得更深入的理解，并且没有我不想要/不需要的不必要的包袱。但是，缺少文档会让这很困难。所以我想在这里问一下，毫无疑问聪明的.NET Core人员正在隐藏;）

我知道这个问题很长，并且有很多子问题。但是我可以通过一个文档链接或者知道某人的一些简单线条来回答这个问题。感谢与我的关系，我希望这可能成为同一船上其他人的有用答案资源，试图了解.NET Core的一个好方法。

首先，global.json。我想在同一个解决方案中使用多个项目和组件。通过另一个SO问题，我发现了这个隐藏的链接：http://dotnet.github.io/docs/project-model/global-json-reference.html - 但似乎没有VS工具可以从头开始设置或使用它。

1）global.json问题

A）这些文档所指的构建系统是什么？ dotnet build？ （对此的帮助表明它只是构建了一个项目 - 如果它有解决方案＆＃39; - 如果它仍然是名称 - 它是否仅在所有子文件夹上运行dotnet build？）。

B）周围的许多例子都有"sdk"属性 - 但EF Core没有它，而且新的＆＃34;单句式＆＃34; docs没有提到它。 The official RC2 migration guide for ASP.NET Core has it它还在吗？如果是这样，为什么需要呢？有什么用？有什么选择吗？

接下来，到project.json和框架。我想了解框架的选项。有清单吗？官方指导？ dotnet new使用netcoreapp1.0; "official docs"使用dnxcore50和this GH discussion from last month的示例也提出了netcore1.0作为框架（与应用）的可能性的问题。

此外，imports。我对命名感到非常困惑 - 文档谈到这是项目兼容的其他框架列表..

2）project.json框架问题 -

A）我在哪里可以找到围绕框架选项的最新或维护的列表或建议？

B）如果我对import的目的的理解是正确的，为什么这样命名呢？如果没有，它究竟导入了什么？

C）为什么每个import属性都有framework属性？如果它表明整个项目与另一个框架兼容，那么这似乎最好放在project.json的顶层，不是吗？

D）我应该如何决定使用哪个import选项？ dotnet new只有dnxcore50 - 哪些包是满足的？ This guy建议dotnet5.6，dnxcore50和portable-net45+win8！

最后，我建立了类库，测试项目，控制台工具。所以..

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的大部分？

Answer 1

你有很多问题。没有单一的文档，因为问题不是那么简单;）

<强> global.json

• global.json构建系统：global.json（as project.json）不指定构建系统（例如msbuild csproj文件除外）。目前，只有dotnet build可用（在VS中使用时由msbuild xproj代理）。这将更改为msbuild，因为完整的工具处于预览/测试阶段，并且不会在6月底发布。它遍历所有子文件夹并构建东西。它也是查找本地项目引用的根节点。
• global.json sdk：这是用于构建的sdk。新的cli也支持多个sdks，我认为这仍然用于选择。

<强> project.json

• project.json框架列表：我建议您阅读platform standard document，然后在那里找到当前框架标记的列表。本文档还将解决您（可能）提出的许多其他问题。完整列表位于NuGet project docs，但该列表再次被弃用，也没有用。您的示例netcore refer用于UWP（运行时也称为.NET Core），而跨平台.NET Core使用netcoreapp，这在NuGet文档中完全缺失。
• project.json导入：你的目的是错误的。在project.json中，您可以指定构建库实现的目标框架（例如netstandard1.6和net451）。 import语句用于为目标框架指定的依赖关系，基本上说：如果TFM（例如netstandard1.6）在引用的库中不存在（因为NuGet是在前一段时间构建的），我也接受这些导入一次（例如已弃用的dotnet5.6或dnxcore50）。这是一个打破NuGet并允许使用尚未移动到新TFM的库的实用程序。它没有说明您的项目，但您接受使用哪些版本的依赖项。这需要针对每个目标框架单独指定，因为NuGet库实现的接受可能因目标框架而异。
• project.json导入用法：好吧，使用你需要的东西并删除你不需要的东西。当您引用尚未迁移到新TFM的NuGets时，您将收到错误。 dnxcore和dotnet是.NET Core项目的保存赌注，因为它们是在当前标记netstandard和netcoreapp创建之前使用的。只是不要大胆添加例如基于net461 / mscorlib的NuGet实现基于netstandard / System.Runtime的目标框架。这不起作用，是一个常见的错误。

<强>依赖关系

• dotnet新默认模板：是的，对于ASP.NET和控制台应用程序来说，它始终是正确的选择。但是，这只是一个简单的控制台应用程序（Web应用程序也是控制台应用程序）。使用Visual Studio在Linux下创建新的ASP.NET Core项目或yeoman以进行高级模板化。 dotnet new不是一个完整的脚手架系统。新模板使用netcoreapp目标框架和Microsoft.NETCore.App元包来导入基本上所有可用的基类库。如果要创建库，请切换到netstandard目标框架并依赖NETStandard.Library。您仍然可以添加其他依赖项。对于ASP.NET核心，没有可用的直接元数据包。指导在此结束。有一个称为修剪的过程，您可以在其中删除这些元包并添加具体的依赖项。但是还没有适合它的工具。
• project.json构建/平台依赖项：build依赖项本质上是工具，在构建期间不会发布。当您知道npm时，您知道此方案为devDependencies。 platform依赖项本质上是一个依赖项，它不与您的应用程序一起部署，而是作为.NET Core SDK的共享基本安装的一部分。您可以在术语＆＃34;便携式应用程序＆＃34;下找到guidance。 （即platform）和＆＃34;自包含的应用程序＆＃34; （就是没有）。
• project.json元包/传递依赖：.NET Core和project.json引入了元包的概念。 Microsoft.NETCore.App本质上是.NET Core命令行应用程序的基线依赖项，而类库是NETStandard.Library。所有这些包都可以拥有自己的代码和其他包的传递依赖。这些你也可以利用。例如，Microsoft.NETCore.App包引用NETStandard.Library，再次引用System.Collections.Generic。因此，在您引用Microsoft.NETCore.App的应用中，您可以使用通用集合。对于 ASP.NET Core ，情况有所不同，因为按需付费的理念对性能至关重要。对于高效的应用程序，您必须了解添加的内容。作为首发，您必须使用VS或yeoman等脚手架系统。 Microsoft.AspNetCore.Server.Kestrel（例如纯文本）或Microsoft.AspNetCore.Mvc（用于web api）可传递地包含大多数其他关键的ASP.NET Core依赖项。

免责声明：上面的大多数主题都与工具有关，被视为＆＃34;预览＆＃34;。 ＆＃34;预览＆＃34;意味着＆＃34; beta＆＃34;。即将发生重大变化（例如将构建系统从project.json切换回msbuild，或再次改进.NET标准）。

我希望这可以回答你的大部分问题。我认为在一个问题中回答所有问题是一个挑战;）。

Answer 2

Global.json reference

Project.json reference

对于Asp.Net项目，请使用NetCore.App。对于类库项目，请使用NETStandard.Library

还有 .Net Core的Api参考，您可以在其中找到文档。