.NET Core-解决方案，框架，导入，运行时 [英] .NET Core - solutions, frameworks, imports, runtimes

问题描述

我正在开始重新设计框架集以使用.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构建？ （这样做的帮助说，它只是构建一个项目-如果它执行解决方案-如果仍然是名称-它是否在所有子文件夹上运行 dotnet build ？） 。

B）周围的许多示例都具有 sdk 属性-但EF Core没有，而新的单句样式文档则没有引用它。 ASP.NET Core的官方RC2迁移指南拥有它仍然存在吗？或不？如果是这样，为什么需要它？有什么用？

---

下一步，转到 project.json 和框架。我想了解这里的框架选项。有清单吗？官方指导？ dotnet新使用 netcoreapp1.0 ; 官方文档 使用 dnxcore50 和上个月的GH讨论也提出了的问题netcore1.0 作为框架（相对于应用程序）的可能性。

此外，进口。对此命名感到很困惑-文档谈论的是项目兼容的其他框架的列表。

2）project.json框架问题-

A）在哪里可以找到有关框架选项的最新或维护清单或建议集？

$ b）如果我对进口的目的的理解是正确的，为什么这样命名？如果不是，它究竟导入什么？

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

D）如何确定应该使用哪些 import 选项？ dotnet新仅具有 dnxcore50 -要满足哪些软件包？ 这家伙建议 dotnet5.6 ， dnxcore50 和 portable-net45 + win8 ！

---

最后，我正在构建类库，测试项目和控制台实用程序。因此。

3）引用和软件包

A）我总是是否要根据 dotnet新 Microsoft.NETCore.App ？还有其他基准选项吗？有关选择的指导？

B）文档没有提及 type 选项（ build ，平台）。

C）我的某些项目将使用ASP.NET。在哪里找到正确的软件包以供参考的最佳位置？ NuGet上似乎有一百万个版本和软件包。 本教程只是谈论引用 Microsoft。 AspNetCore.Server.Kestrel -唯一引用的ASP.NETty是 Microsoft.AspNetCore.Hosting 。

解决方案

您有很多问题。没有单个文档，因为问题不是那么简单；）

global.json

• global.json构建系统：global.json（作为project.json）未指定构建系统（例如msbuild csproj文件除外）。目前，只有 dotnet build 可用（在VS中使用msbuild xproj代理）。这将更改为 msbuild ，因为完整的工具位于预览/测试版中，而不会在6月底发布。它在所有子文件夹上运行并生成内​​容。它也是查找本地项目引用的根节点。


• global.json sdk：这是用于构建的sdk。新的cli还支持多个sdks，我认为仍用于选择。

project.json

• project.json框架列表：我建议您阅读平台标准文档，您会在其中找到当前框架名称的列表。本文档还将解决您（可能）遇到的许多其他问题。完整列表位于 NuGet项目文档中，但该列表再次被弃用，也没有太大用处。您的示例 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导入用法：好吧，使用所需的内容并删除所有不需要的内容。当您引用尚未迁移到新TFM的NuGet时，会出现错误。 dnxcore 和 dotnet 是.NET Core项目上的节省赌注，因为它们是在当前名称<$ c $之前使用的c> netstandard 和 netcoreapp 被创造出来。只是不要那么大胆地​​添加例如 net461 / mscorlib的NuGet实现到 netstandard /System.Runtime的目标框架。那是行不通的，是一个常见的错误。

依赖项

• dotnet新的默认模板：是的，对于ASP.NET和Console Apps，这始终是正确的选择。但是，这只是一个简单的控制台应用程序（Web应用程序也是控制台应用程序）。使用Visual Studio在Linux下创建新的ASP.NET Core项目或yeoman以进行高级模板化。 dotnet new 并非完整的脚手架系统。新模板使用 netcoreapp 目标框架和 Microsoft.NETCore.App 元包导入基本上所有可用的基类库。如果要创建库，请切换到 netstandard 目标框架，并依赖 NETStandard.Library 。您仍然可以添加其他依赖项。对于ASP.NET核心，没有直接的元数据包可用。指导到此结束。有一个称为修整的过程，您可以在其中删除这些元数据包并添加具体的依赖项。


• project.json构建/平台依赖项： build 依赖项本质上是工具，不是在构建期间发布。当您知道 npm 时，您就会将此方案称为 devDependencies 。 平台依赖关系本质上是一个依赖关系，它不会与您的应用程序一起部署，而是作为.NET Core SDK共享基础安装的一部分。您可以在便携式应用程序一词下找到指南。是平台）和自包含应用程序（就是没有）。


• 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依赖项。

免责声明：上面的大多数主题与工具相关，被认为是预览。 预览是指测试版。即将发生重大变化（例如将构建系统从project.json切换回msbuild，或再次完善.NET标准）。

I希望这能回答您的大多数问题。我认为在一个问题中回答所有问题都是一个挑战；）。

I'm starting the process of reworking a framework set of libraries to use .NET Core. Thought I'd wait for RC2 and keen to get stuck in.

I'm taking the opportunity to get up close and personal with the build system, configs, code everything from scratch to get a deeper understanding and have no unnecessary baggage that I don't want/need. However, the lack of documentation makes this quite difficult.. so I wanted to ask here, where no doubt clever .NET Core folks are hiding ;)

I know this question is long and has lots of sub-questions. But it could be answered I feel by a single link to documentation, or a few succint lines from someone in the know. Thanks for bearing with me, and I hope that this might become a useful answer resource for others in the same boat, trying to understand a good approach for .NET Core.

---

First, global.json. I want multiple projects and components in the same 'solution'. Through another SO question I found this hidden link: http://dotnet.github.io/docs/project-model/global-json-reference.html - but there seems to be no VS tooling for setting up or using this from scratch.

1) global.json questions

A) What build system do these docs refer to? dotnet build? (The help for that says it just builds a project - if it does 'solutions' - if that's still the name - does it just run dotnet build over all child folders?).

B) Many examples around have an "sdk" property - but EF Core doesn't have it, and the new "single-sentence-style" docs don't refer to it. The official RC2 migration guide for ASP.NET Core has it Is it still around or not? If so, why is it needed? What uses it? What are the options for it?

---

Next up, to project.json and frameworks. I want to understand the options here for frameworks. Is there a list? Official guidance? dotnet new uses netcoreapp1.0; "official docs" use an example of dnxcore50 and this GH discussion from last month also raises the question of netcore1.0 as a possibility for frameworks (vs apps).

Furthermore, imports. Am quite baffled on the naming - the docs talk about this being a list of other frameworks that the project is compatible with..

2) project.json framework questions -

A) Where can I find an up-to-date or maintained list or set of advice around the framework options?

B) If my understanding of the purpose of import is correct, why is it named so? If not, what exactly does it import?

C) Why is there an import property for every framework property? If it's to indicate the whole project is compatible with another framework, that would seem to be best placed at the top level of project.json, no?

D) How should I decide which import options should I use? dotnet new has just dnxcore50 - which packages is that to satisfy? This guy suggests dotnet5.6, dnxcore50 and portable-net45+win8!

---

Finally, I'm building class libraries, test projects, console utils. So..

3) references and packages

A) Do I always want Microsoft.NETCore.App as per dotnet new? Are there other baseline options? Guidance on choosing? A list?

B) The docs don't mention anything about the type option (build, platform). Is there any guidance available on these?

C) Some of my projects will use ASP.NET. Where's the best place to find the correct packages to reference? There seem to be a million versions and packages on NuGet. This tutorial just talks about referencing Microsoft.AspNetCore.Server.Kestrel - and the only ASP.NETty thing that refs is Microsoft.AspNetCore.Hosting. Does that mean that one package is most of ASP.NET?

解决方案

You have many questions. There is no single documentation for it, because the questions are not that simple ones ;)

global.json

• global.json build system: global.json (as project.json) do not specify a build system (other than e.g. msbuild csproj files). For now, only dotnet build is available (proxied by msbuild xproj when used in VS). This is going to change to msbuild because the complete tooling is in preview/beta and not going to release end of June. It runs over all the child folders and build the stuff. It is also the root node for looking up local project references.
• global.json sdk: That is the sdk used for the build. The new cli also supports multiple sdks, and I think this is still used for selection.

project.json

• project.json list of framework: I recommend that you read the 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, but the list again is deprecated and not that useful either. You example netcore refers is used for UWP (which runtime is also called .NET Core) while the cross-platform .NET Core uses netcoreapp which is completely missing in NuGet documentation.
• project.json import: you get here the purpose wrong. In project.json you specify the target frameworks for which implementations of your library are build (e.g. netstandard1.6 and net451). The import statement is used for dependencies you specify for the target framework and basically says: If the TFM (e.g. netstandard1.6) does not exist in a referenced library (because the NuGet was build a while ago), I also accept these imported once (e.g. the deprecated dotnet5.6 or dnxcore50). This is currently a utility to break NuGet and allow the usage of libraries which are not yet moved to the new TFMs. It does not say anything about your project but which versions of your dependencies you accept to use. That needs separate specification for each targeted frameworks because acceptance of NuGet library implementations might differ per targeted framework.
• project.json import usage: well, use what you need and remove all you do not need. You will get errors when you refer NuGets which have not been migrated yet to the new TFM. dnxcore and dotnet are save bets on .NET Core projects because they have been used before the current monikers netstandard and netcoreapp have been coined. Just do not be that bold to add e.g. net461/mscorlib based NuGet implementations to a netstandard/System.Runtime based target framework. That does not work and is a common mistake.

dependencies

• dotnet new default template: Yes, for ASP.NET and Console Apps that is always the right choice. However, this is just a simple console app (web apps are console apps as well). Use Visual Studio to create new ASP.NET Core projects or yeoman under Linux for advanced templating. dotnet new is not a full blown scaffolding system. The new template uses the netcoreapp target framework and the Microsoft.NETCore.App meta packages to import basically all available base class libraries. If you want to create a library, switch to netstandard target framework and depend on the NETStandard.Library. You can still add other dependencies. For ASP.NET core, no direct meta package is available. The guidance ends here. There is a process called trimming, where you remove these meta packages and add concrete dependencies instead. But there is not yet tooling for it.
• project.json build/platform dependencies: build dependencies are essentially tools, which are not published during build. When you know npm you know this scheme as devDependencies. platform dependencies is essentially a dependency which is not deployed along with your app but as part of the shared base installation of the .NET Core SDK. You find guidance here under the term "portable application" (that is platform) and "self-contained application" (that is it without).
• project.json meta packages / transitive dependencies: .NET Core and project.json introduce the concept of meta packages. Microsoft.NETCore.App is essentially the baseline dependency for a .NET Core command line app and NETStandard.Library for class libraries. All these packages can have code on their own and transitive dependencies for other packages. These you can also utilize then. As an example, the Microsoft.NETCore.App package refers NETStandard.Library which again refers System.Collections.Generic. So in your app which refers Microsoft.NETCore.App you can use generic collections. For ASP.NET Core the situation is different, because there the pay-as-you-go philosophy is very performance critical. For productive application you have to understand what you add. As a starter, you have to use scaffolding systems like VS or yeoman. The Microsoft.AspNetCore.Server.Kestrel (e.g. plain text) or Microsoft.AspNetCore.Mvc (for web api) transitively include most other critical ASP.NET Core dependencies.

Disclaimer: Most of the topics are above are related to tooling which is considered "preview". "preview" means "beta". There are significant changes upcoming (like switching the build system from the project.json back to msbuild, or refining the .NET standard once more).

I hope this answers most of your questions. I think answering all of them in one question is a challenge ;).

这篇关于.NET Core-解决方案，框架，导入，运行时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！