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

Я начинаю процесс доработки набора библиотек для использования.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

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

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

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

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

2) вопросы фреймворка project.json -

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

Б) Если мое понимание цели import правильно, почему он так назван? Если нет, что именно он импортирует?

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

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

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

3) ссылки и пакеты

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

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

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

Источник

2 ответа

Решение

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

global.json

  • Система сборки global.json: global.json (как project.json) не указывает систему сборки (кроме, например, файлов msbuild csproj). Пока только dotnet build доступно (прокси через msbuild xproj при использовании в VS). Это изменится на msbuild потому что полный набор инструментов находится в предварительном / бета-версии и не собирается выпускать в конце июня. Он работает над всеми дочерними папками и создает вещи. Это также корневой узел для поиска ссылок на локальные проекты.
  • global.json sdk: это sdk, используемый для сборки. Новый Cli также поддерживает несколько SDK, и я думаю, что это все еще используется для выбора.

project.json

  • project.json список фреймворков: я рекомендую вам прочитать стандартный документ платформы и там вы найдете список текущих имен фреймворков. Этот документ также решит многие другие вопросы, которые у вас могут возникнуть. Полный список находится в документации проекта NuGet, но этот список снова устарел и тоже не очень полезен. Вы пример netcore ссылка используется для UWP (которая также называется.NET Core), а кроссплатформенная .NET Core использования netcoreapp который полностью отсутствует в документации NuGet.
  • import.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 / Nuscet на основе mscorlib реализации в netstandard /System.Runtime основанная целевая структура. Это не работает и является распространенной ошибкой.

зависимости

  • dotnet новый шаблон по умолчанию: Да, для ASP.NET и консольных приложений это всегда правильный выбор. Тем не менее, это всего лишь простое консольное приложение (веб-приложения также являются консольными приложениями). Используйте Visual Studio для создания новых проектов ASP.NET Core или yeoman под Linux для расширенных шаблонов. dotnet new не полноценная система строительных лесов. Новый шаблон использует netcoreapp целевые рамки и Microsoft.NETCore.App метапакеты для импорта в основном всех доступных библиотек базовых классов. Если вы хотите создать библиотеку, переключитесь на netstandard целевые рамки и зависят от NETStandard.Library, Вы все еще можете добавить другие зависимости. Для ядра ASP.NET прямой метапакет недоступен. Руководство заканчивается здесь. Существует процесс, называемый усечением, при котором вы удаляете эти метапакеты и вместо этого добавляете конкретные зависимости. Но для этого пока нет инструментов.
  • Зависимости build/ платформы проекта.json: build зависимости - это инструменты, которые не публикуются во время сборки. Когда ты знаешь npm Вы знаете эту схему как devDependencies, platform Зависимости - это, по сути, зависимость, которая развертывается не вместе с вашим приложением, а как часть установки совместно используемой базы.NET Core SDK. Вы найдете руководство здесь под термином "портативное приложение" (то есть platform) и "автономное приложение" (то есть без него).
  • метапакеты 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 (для веб-API) транзитивно включают большинство других критических зависимостей ASP.NET Core.

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

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

Источник

Global.json ссылка

Ссылка на Project.json

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

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

Источник
Другие вопросы по тегам