.NET Core - решения, рамки, импорт, время автономной работы

Я начинаю переработку набора фреймворков для использования .NET Core. Думал, что я буду ждать RC2 и очень хочу застрять.

Я пользуюсь случаем, чтобы встать близко и лично с системой сборки, конфигурациями, кодировать все с нуля, чтобы получить более глубокое понимание и не иметь ненужного багажа, который мне не нужен/нужен. Однако отсутствие документации делает это довольно сложным. Поэтому я хотел спросить здесь, где, без сомнения, умные люди .NET Core скрываются;)

Я знаю, что этот вопрос длинный, и у него много вопросов. Но на него можно было ответить, я чувствую себя по одной ссылке на документацию, или несколько строк сукцинта от кого-то в курсе. Спасибо за поддержку, и я надеюсь, что это может стать полезным ресурсом для других пользователей на одной лодке, пытаясь понять хороший подход к .NET Core.

Сначала global.json. Я хочу, чтобы несколько проектов и компонентов находились в одном и том же "решении". Через другой вопрос SO я нашел эту скрытую ссылку: http://dotnet.github.io/docs/project-model/global-json-reference.html - но, похоже, нет никакого инструмента VS для настройки или использования этого с нуля.

A) В какой системе сборки эти документы ссылаются? dotnet build? (Помощь для этого говорит, что он просто создает проект - если он делает "решения" - если это еще имя - он просто запускает dotnet build поверх всех дочерних папок?).

B) Многие примеры имеют свойство "sdk", но EF Core не имеет его, а новые документы с одним предложением - не ссылаются на него. В официальном руководстве по перенастройке RC2 для ASP.NET Core есть оно. Это все еще вокруг или нет? Если да, то зачем это нужно? Что его использует? Каковы его варианты?

Далее, до project.json и фреймворки. Я хочу понять варианты здесь для фреймворков. Есть ли список? Официальное руководство? dotnet new использует netcoreapp1.0; "официальные документы" используют пример dnxcore50 и этого обсуждения GH за последний месяц, также поднимает вопрос netcore1.0 как возможность для фреймворков (vs apps).

Кроме того, imports. Меня совершенно озадачивает именование - речь в документах о том, что это список других фреймворков, совместимых с проектом.

A) Где я могу найти обновленный или поддерживаемый список или набор советов вокруг вариантов структуры?

B) Если мое понимание цели import верное, почему это так называется? Если нет, что именно он импортирует?

C) Почему существует свойство import для каждого свойства framework? Если он указывает на то, что весь проект совместим с другой структурой, это будет лучше всего размещаться на верхнем уровне project.json, no?

D) Как мне решить, какие опции import использовать? dotnet new имеет только dnxcore50 - какие пакеты должны удовлетворять? Этот парень предлагает dotnet5.6, dnxcore50 и portable-net45+win8!

Наконец, я строю библиотеки классов, тестовые проекты, консольные утилиты. Так..

A) Всегда ли я хочу Microsoft.NETCore.App согласно dotnet new? Существуют ли другие базовые варианты? Руководство по выбору? Список?

B) В документах ничего не говорится о опции type (build, platform). Есть ли какие-либо рекомендации по этим вопросам?

C) Некоторые из моих проектов будут использовать ASP.NET. Где лучше всего найти правильные пакеты для ссылки? На NuGet существует миллион версий и пакетов. В этом руководстве говорится только о ссылках Microsoft.AspNetCore.Server.Kestrel - и единственная вещь ASP.NETty, которая ссылается на Microsoft.AspNetCore.Hosting. Означает ли это, что один пакет является частью ASP.NET?

Ответы

Ответ 1

У вас много вопросов. Для этого нет единой документации, потому что вопросы не такие простые;)

global.json

global.json build system: global.json(as project.json) не указывают систему сборки (кроме файлов msbuild csproj). Пока доступно только dotnet build (проксируется msbuild xproj при использовании в VS). Это изменится на msbuild, потому что полная оснастка находится в предварительном просмотре/бета-версии и не будет выпущена в конце июня. Он запускает все дочерние папки и создает материал. Это также корень node для поиска локальных ссылок на проект.
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: ну, используйте то, что вам нужно, и удалите все, что вам не нужно. Вы получите ошибки, когда ссылаетесь на NuGets, которые еще не были перенесены в новый TFM. dnxcore и dotnet сохраняют ставки в проектах .NET Core, потому что они использовались до того, как были введены текущие прозвища netstandard и netcoreapp. Просто не будьте смелыми, чтобы добавить, например. net461/mscorlib основанные на NuGet реализации в netstandard/System.Runtime основе целевой структуры. Это не работает и является распространенной ошибкой.

зависимостей

dotnet новый шаблон по умолчанию: Да, для приложений ASP.NET и консолей, которые всегда являются правильным выбором. Однако это просто консольное приложение (веб-приложения также являются консольными приложениями). Используйте Visual Studio для создания новых проектов ASP.NET Core или yoman под Linux для расширенного шаблонирования. dotnet new не является полностью раздутой системой лесов. Новый шаблон использует целевую структуру netcoreapp и мета-пакеты Microsoft.NETCore.App для импорта в основном всех доступных библиотек базового класса. Если вы хотите создать библиотеку, переключитесь на netstandard целевую структуру и зависеть от NETStandard.Library. Вы можете добавить другие зависимости. Для ядра ASP.NET прямой мета-пакет недоступен. Руководство заканчивается здесь. Существует процесс под названием обрезка, в котором вы удаляете эти метапакеты и вместо этого добавляете конкретные зависимости. Но для этого еще нет инструментов.
Зависимости сборки/платформы project.json: зависимости build - это, по сути, инструменты, которые не публикуются во время сборки. Когда вы знаете npm, вы знаете эту схему как devDependencies. platform зависимости - это, по сути, зависимость, которая не развертывается вместе с вашим приложением, а как часть общей базовой установки .NET Core SDK. Вы найдете руководство здесь под термином "переносное приложение" (то есть platform) и "автономное приложение" (то есть без него).
project.json meta packages/transitive dependencies:.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 ситуация отличается, потому что философия pay-as-you-go очень критична для производительности. Для продуктивного применения вы должны понимать, что вы добавляете. В качестве стартера вы должны использовать системы лесов, например, VS или yoman. Microsoft.AspNetCore.Server.Kestrel (например, обычный текст) или Microsoft.AspNetCore.Mvc (для веб-api) транзитивно включают большинство других критических зависимостей ядра ASP.NET.

Отказ от ответственности. Большинство вышеперечисленных тем связаны с инструментами, которые считаются "предварительными". "Предварительный просмотр" означает "бета". Наступают значительные изменения (например, переключение системы сборки из project.json обратно в msbuild или усовершенствование стандарта .NET еще раз).

Надеюсь, это ответит на большинство ваших вопросов. Я думаю, что ответить на все из них в одном вопросе - это вызов;).

Ответ 2

Ссылка Global.json

Ссылка Project.json

Для проекта Asp.Net используйте NetCore.App. Для проекта библиотеки классов используйте NETStandard.Library

Также существует ссылка Api для .Net Core, где вы можете найти документацию.