Ответ 1
Ответ показан в презентации
Только с ASP.NET Core RC 2, который еще не выпущен, будет добавлена поддержка ссылки на xproj в csproj.
Возможно, у меня отсутствует понимание того, что означает ".NET Core Library", но когда я пытаюсь добавить .NET Core Library в сборку .NET 4.6 с помощью Visual Studio 2015, я получаю сообщение об ошибке:
Ссылка на "..." не может быть добавлена.
Я понял что-то не так?
Это то, что я сконфигурировал в project.json сборки .NET Core
"frameworks": {
"net451": { },
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Collections": "4.0.11-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading": "4.0.11-beta-23516"
}
}
Ответ показан в презентации
Только с ASP.NET Core RC 2, который еще не выпущен, будет добавлена поддержка ссылки на xproj в csproj.
Теперь это можно сделать с .Net Core RC2. Вот как:
project.json
настроены на включение соответствующей инфраструктуры .net. Например, в этом разделе приведена ссылка .Net 4.51, которая может быть ссылкой любой из фреймворков, равных или выше этой версии:Пример:
"frameworks": {
"net451": { },
"netstandard1.5": {
"dependencies": {
"NETStandard.Library": "1.5.0-rc2-24027"
},
"imports": [
"portable-net45+wp80+win8+wpa81+dnxcore50",
"portable-net451+win8"
]
}
},
Пакет приложения RC2 как пакет Nuget. Я еще не видел, как это сделать из Visual Studio, но это можно сделать из командной строки:
dotnet pack -o e:\packages
Если вы хотите обновить его на каждой сборке, вы можете добавить следующее в файл project.json, который автоматически обновляет пакет в родительском каталоге.:
"scripts": {
"postcompile": [
"dotnet pack --no-build --configuration Debug -o ..//..//..//packages"
]}
Добавьте пакет Nuget в ваше приложение .net 4.6. Это можно сделать несколькими способами. Простым способом является добавление местоположения, в котором вы сохранили пакет, в качестве ссылки источника пакета.
Увеличивайте номер версии в файле project.json
каждый раз, когда вы создаете, чтобы убедиться, что ваши другие приложения видят обновление.
Измените свою библиотеку классов (и любых иждивенцев) на сборку с 4.6, а также .NET Core;
Теперь вы создадите обе версии библиотеки классов для вас.
В вашем проекте .NET 4.6 (App) добавьте прямую ссылку на библиотеку DLL библиотеки классов, найденную в папке отладки
Теперь вы можете импортировать это пространство имен и создать против него. Хотя ReSharper (2016.3 EAP 2), похоже, запутался и отмечает эти строки красным цветом - это остановка в промежутке до поздних версий .NET.
Если вы откроете файл проекта приложения (.csproj), вы увидите ссылку, добавленную каркасом.
NB: код сборки dnx462, похоже, не работает, жалуется, что среда .NET не установлена, хотя проект имеет приложение WP.2 4.6.2.
Я нашел очень простое решение, которое хорошо работает, если вы не возражаете против hardcoding ссылки на Debug или Release. Вы просто вручную добавляете ссылку на свой xproj в файле csproj. Вот как вы это делаете:
Найдите часть в файле проекта csproj, где вы ссылаетесь на пакет nuget. Ах... вот один:
<Reference Include="Microsoft.CodeAnalysis, Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.CodeAnalysis.Common.1.3.0\lib\net45\Microsoft.CodeAnalysis.dll</HintPath>
<Private>True</Private>
</Reference>
Скопируйте это и измените его для ссылки на DLL, созданный вашим проектом xproj, например:
<Reference Include="HighFive.Server.Web">
<HintPath>..\HighFive.Server.Web\bin\Debug\net461\HighFive.Server.Web.dll</HintPath>
<Private>True</Private>
</Reference>
Что касается жесткого кодирования либо справки отладки или релиза: для проектов unit test это не проблема, поскольку вы обычно выполняете модульные тесты в режиме отладки. Я уверен, что это можно было бы сделать даже более разумным, используя параметры MSBuild, чтобы избежать жесткого кодирования, но мне не нужно было это делать.
Я тоже борется с этим, но нашел лучшее решение, чем громоздкое решение для пакетов nuget. Я нашел это в Stackify. В этом сообщении обсуждается только отдельное решение, но довольно просто использовать только одно решение.
Эти параметры подразумевают наличие двух файлов решений вместе с двумя файлами проекта для каждого проекта с использованием как .NET core, так и .NET 4.x.x. Сначала создайте новое чистое решение. Затем создайте новую Windows "Class Library" (то, что вы называете, на данный момент не имеет значения). Удалите это из решения, чтобы вы могли редактировать файл .csproj. Откройте файл .csproj и измените XML-элемент AssemblyName
на имя сборки основного проекта .NET. Теперь вы должны внести в проект какие-либо другие изменения, связанные с именем. Закройте .csproj и переименуйте его так же, как ваш .xproj файл. Скопируйте его в ту же папку, что и файл .xproj.
Теперь, когда ваш новый блестящий файл .csproj готов, вот где происходит волшебство. Создайте файл с именем ProjectName.project.json
и добавьте в него этот текст (при необходимости измените структуру .net)
{ "runtimes": { "win": {} }, "frameworks": { "net461": {} }}
В решении .NET 4.x.x перезагрузите этот измененный файл .csproj, и вы можете добавить свои исходные файлы. Я нашел, что самый простой способ сделать это - нажать "Показать все файлы" и нажать "Включить в проект" в контекстном меню правой кнопки мыши для каждого файла/папки. Теперь попробуйте построить .csproj, и он должен хорошо работать. Если это не работает правильно, попробуйте либо перезагрузить проект, либо перезапустить визуальную студию.
Это то же самое, что и предыдущее, но с несколькими ключевыми отличиями. Имя файла .csproj должно быть иначе, чем имя .xproj(я просто добавил суффикс, например MyProjectName.win.csproj
и MyProjectName.win.project.json
). Они могут быть добавлены в одно и то же решение без конфликта имен. Вы даже можете иметь элемент AssemblyName
в .csproj так же, как и имя сборки ядра .NET, потому что папка вывода изменяется в зависимости от версии .NET
Я нашел это решение намного лучше, чем вариант пакета nu-get. Единственное, о чем нужно подумать, это все модификации любых ссылок, пакеты nu-get или любые новые файлы должны быть добавлены в оба проекта; Это небольшая цена, чтобы заплатить, чтобы избежать страшной опции пакета nu-get. Давайте просто скрестим пальцы и надеемся, что команда VS может получить ссылки .xproj в файлах .cspoj, работающих как можно скорее.
Я знаю, что не должен размещать ссылки, однако я бы хотел отдать должное там, где это необходимо. http://stackify.com/using-both-xproj-and-csproj-with-net-core/