Как я могу создать библиотеку классов .NET Core и ссылаться на нее из проекта .NET 4.6?

Я хочу:

Сделать библиотеку классов, которая определяет некоторые интерфейсы и простые общие вспомогательные классы. Он будет опираться на общие коллекции и IQueryable<T>, но не имеет сторонних зависимостей (ну, JetBrains.Annotations).
Уметь ссылаться на эту библиотеку классов всюду (в частности, UWP, net46 и ASP.Net Core RC2)
В идеале используйте всю систему project.json, хотя я готов пожертвовать тем, что в случае необходимости.
Публикация готовой библиотеки в фид NuGet и использование ее в других приложениях

При создании проекта библиотеки классов в Visual Studio 2015.2 я нашел шаблон Class Library (.NET Core), в котором указано

Шаблон проекта для создания библиотеки классов в виде пакета NuGet, который может ориентироваться на любую платформу

Любая платформа! Блестящий... Но я не могу заставить его работать. После многих упражнений в настоящее время у меня есть следующий project.json (я, вероятно, полностью его сломал):

{
"title": "My Really Useful Class Library",
"copyright": "Copyright © 2015-16 Tigra Astronomy, all rights reserved",
"description": "Really neat stuff",
"language": "en-GB",
"version": "1.0.0-*",
"dependencies": {
    "JetBrains.Annotations": "10.1.4",
    },
"frameworks": {
    "netstandard1.5": {
        "imports": "dnxcore50",
        "dependencies": {
            "NETStandard.Library": "1.5.0-rc2-24027",
            "System.Linq.Expressions": "4.0.11-rc2-24027"
            }
        }
    "net46": {
        "frameworkAssemblies": {
            "System.Collections": "4.0.*"
            },
        "dependencies": {}
        }
    },
    "buildOptions": {
        "xmlDoc": true
        }
}

Следующее, что я сделал, это создать проект .NET Framework 4.6 в том же решении и попытаться ссылаться на библиотеку классов. Это позволяет мне добавить ссылку, но я получаю ошибки сборки, неразрешенные символы, R # недоволен и т.д.

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

Я прочитал некоторые документы о TFM, фреймворках и библиотеках, но ничто из этого не имеет особого смысла.

Что мне действительно нужно помещать в мою библиотеку классов project.json, чтобы я мог ссылаться на нее из моего приложения .net framework 4.6, а также из приложений UWP и ASP.NET Core RC2? Действительно ли это правильный подход или я начал на неправильной ноге?

Ответ 1

Сейчас есть два способа создания проектов С#: xproj и csproj. Предполагая, что мы используем project.json для обоих из них, которые по-прежнему работают по-разному для типов проектов - для xproj, project.json содержит все необходимое для построения проекта; для csproj он содержит только нулевые зависимости.

Тем не менее, некоторые типы проектов, такие как UWP, не могут быть построены с помощью xproj из-за необходимости более сложного конвейера сборки, чем поддерживает xproj/project.json. (Кстати, это была одна из ключевых причин для возврата к msbuild.)

Существует также два способа создания библиотеки классов .NET Standard: вы можете использовать xproj с project.json, как вы это делали, или создать обычную библиотеку переносимых классов csproj проект. С помощью VS 2015 Update 3 RC вы можете изменить PCL, чтобы настроить стандартную версию .NET(netstandard1.x вместо профиля PCL, 259 и т.д.).

Если вы используете библиотеку классов, основанной на csproj для таргетинга на netstandard1.x, все должно работать только для вас при добавлении ссылок на проекты. Обратите внимание, что в настоящее время UWP поддерживает до netstandard1.4 на основе карты . Задача состоит в том, чтобы вместо этого использовать проект xproj/project.json. Одной из основных причин использования xproj сегодня является возможность кросс-компиляции между несколькими целевыми структурами. То есть, создайте более одного выхода из вашего проекта. Это отличается от создания одного вывода, на который можно ссылаться из любого совместимого проекта. Оба имеют свое применение, это зависит от ваших потребностей.

Если вы решили создать библиотеку классов, основанной на xproj, обходной путь, который вы можете использовать для ссылки на него из проекта UWP или любого другого типа совместимого проекта, если диалог "Добавить ссылки" не работает (что не как csproj → xproj в значительной степени сломан). Вместо использования диалога отредактируйте свой UWP csproj, чтобы указать на вывод xproj следующим образом:

<Reference Include="System.Reactive.Interfaces">
  <HintPath>..\System.Reactive.Interfaces\bin\$(Configuration)\netstandard1.0\System.Reactive.Interfaces.dll</HintPath>
</Reference>

Вышеприведенный фрагмент взят из Rx.NET UWP Test Runner здесь

Если вы это сделаете, вам также нужно будет добавить зависимость сборки от вашего проекта UWP к вашему xproj, поскольку MSBuild/Visual Studio не узнает об этом и не строит вещи в неправильном порядке. Для этого щелкните правой кнопкой мыши по проекту UWP в обозревателе решений, затем выберите "Build Dependencies → Project Dependencies". В этом диалоговом окне установите флажок для вашего xproj, чтобы убедиться, что VS/MSbuild знает, как его сначала создать.

Здесь вы можете увидеть полное решение Rx.NET, которое включает ссылки xproj->xproj и ссылки UWP → xproj, о которых я упоминал выше.

Ответ 2

Новые шаблоны проектов /.xproj работают по-другому. Новые библиотеки классов (и шаблоны приложений) создают пакеты nuget, а не простые сборки.

В этом пакете nuget все цели упаковываются в него. При этом вы добавляете новый проект так же, как вы добавляете любой другой пакет nuget: вы помещаете nuget в фид нуджера, ссылаетесь на него в Visual Studio, а затем извлекаете его оттуда.

Если у вас нет сервера nuget (пакет Visual Studio Team Services + NuGet, myget, self-hosting), вы также можете поместить пакеты в папку (локальный или сетевой ресурс) и добавить эту папку в качестве нужного источник.

Если это "слишком" много работает, вы также можете создать два проекта в одну папку: A *.csproj и *.xproj. *.csproj нацелен на .NET 4.6 Framework, а *.xproj остается, как вы указали выше, и имеет несколько целей. С помощью этой настройки вы обычно можете ссылаться на проект так, как вы использовали раньше (если они находятся в одном решении), просто добавив ссылку.