Ссылка на проект ASP.NET Core RC2 "Зависимость X не может быть решена"

Ответ 1

Вы можете указать:

• Классическая библиотека классов С# из project.json таргетинга на полную инфраструктуру dotnet
• Библиотека классов PCL С# из project.json таргетинга на полную инфраструктуру dotnet и/или CoreCLR

Если ваша библиотека классов С# не является PCL, вы можете ссылаться только на нее из полного раздела dotnet (net*) в project.json

Чтобы ссылаться на VS, щелкните правой кнопкой мыши по проекту → Ссылки → Выберите проект

Ответ 2

Как только https://github.com/dotnet/cli/issues/3199 будет разрешен, ответ Виктора должен работать. Тем временем я использую следующую работу:

Обзор

Каждый раз, когда я создаю проект библиотеки классов, я создаю пакет NuGet с новыми номерами версий. Мой ASP.NET Core RC2 project.json ссылается на пакет NuGet как на обычную зависимость с подстановочной ссылкой (*). Затем я хочу, чтобы мой проект ASP.NET Core RC2 восстанавливал пакеты после каждого его создания, тем самым он подбирает последние изменения.

Решение

Создать пакет NuGet после каждой сборки

В проекте библиотеки классов добавьте ссылку NuGet на https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild

Это создаст структуру папок в вашем проекте следующим образом:

Измените файл Config.ps1 и измените $appendConfigurationAndPlatformToNuGetPackageFileName на $false. (Я обнаружил, что моя ссылка не работает корректно с этим набором на $true)

Если вы хотите отлаживать проект своего класса, измените $packOptions = "" на $packOptions= "-Symbols"

В этот момент, если вы собираетесь создать свой проект, в вашем выходном каталоге будет создан пакет NuGet (обычно bin). Этот script использует файл AssemblyInfo.cs для управления номером версии пакета.

Обновить версию AssemblyInfo.cs

Добавьте script, чтобы обновить версию файла AssemblyInfo.cs после каждой сборки сейчас и измените расположение наших пакетов NuGet в локальном репозитории.

Я пошел и добавил этот script к моему проекту: https://github.com/eoincampbell/powershell-scripts/blob/master/Update-AssemblyFileVersion.ps1 Каждый раз, когда вы его вызываете, он обновляет AssemblyInfo.cs номера версий.

Я немного изменил script, чтобы обновить строки AssemblyFileVersion и AssemblyVersion. Изменить

if ($_.StartsWith("[assembly: AssemblyFileVersion")) {

to

if ($_.StartsWith("[assembly: AssemblyFileVersion") -or $_.StartsWith("[assembly: AssemblyVersion")) {

Автоматизация сборки

Теперь мы хотим, чтобы этот script произошел после каждой сборки, поэтому нам не нужно вручную запускать script каждый раз. Кроме того, я собираюсь изменить расположение вывода NuGet моей библиотеки классов, поскольку у меня есть несколько проектов библиотеки классов в моем решении, на которое ссылается проект ASP.NET Core.

Измените файл .csproj библиотеки классов. Вы найдете что-то похожее на это:

  <PropertyGroup>
    <PostBuildEvent>REM Create a NuGet package for this project and place the .nupkg file in the project output directory.
REM If you see this in Visual Studio Error List window, check the Output window Build tab for the actual error.
ECHO Creating NuGet package in Post-Build event...
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "&amp; '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\CreateNuGetPackage.ps1' -ProjectFilePath '$(ProjectPath)' -OutputDirectory '$(TargetDir)' -BuildConfiguration '$(ConfigurationName)' -BuildPlatform '$(PlatformName)'"</PostBuildEvent>
  </PropertyGroup>

Добавьте PreBuildEvent для запуска script и измените свой -OutputDirectory на локальный репозиторий NuGet (если у вас уже есть). В противном случае вы можете сбросить пакеты в общую папку для всех библиотек классов этого решения (что я и сделал)

  <PropertyGroup>
    <PreBuildEvent>
      ECHO Starting Pre Build Event
      PowerShell -NoProfile -ExecutionPolicy Bypass -Command "&amp; '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\Update-AssemblyFileVersion.ps1' -assemblyInfoFilePath '$(TargetDir)..\\..\\Properties\\AssemblyInfo.cs'
    </PreBuildEvent>
    <PostBuildEvent>REM Create a NuGet package for this project and place the .nupkg file in the project output directory.
REM If you see this in Visual Studio Error List window, check the Output window Build tab for the actual error.
ECHO Creating NuGet package in Post-Build event...
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "&amp; '$(ProjectDir)_CreateNewNuGetPackage\DoNotModify\CreateNuGetPackage.ps1' -ProjectFilePath '$(ProjectPath)' -OutputDirectory '$(TargetDir)..\\..\\..\\LocalPackages\' -BuildConfiguration '$(ConfigurationName)' -BuildPlatform '$(PlatformName)'"</PostBuildEvent>
  </PropertyGroup>

Если вы собираетесь строить сейчас, пакеты NuGet будут создаваться каждый раз, но ваше приложение ASP.NET Core не будет собирать новые пакеты. Чтобы решить эту проблему, я добавил команду pre compile в dotnet restore.

Примечание: intellisense не прав, используйте precompile not prebuild (см. https://github.com/dotnet/cli/issues/3338 для получения дополнительной информации)

  "scripts": {
    "precompile": "dotnet restore",
    "prepublish": [ "npm install", "bower install", "gulp copy", "gulp clean", "gulp min" ],
  }

ASP.NET Core RC2 project.json

Мои ссылки - это просто нормальные зависимости:

"dependencies": {
    "Microsoft.AspNetCore.Mvc.Core": "1.0.0-rc2-final",
    .
    .
    "Lib.IO": "*",
    "Lib.Core": "*",
    "Lib.Data": "*",
}

Выдающиеся проблемы

• Я не беспокоился о написании script для очистки моего репозитория NuGet, потому что после дня кодирования я найду десятки моей библиотеки классов пакеты. Пока я просто вручную очищаю их в конце день/неделю.

• Каждый раз, когда вы создаете ядро ​​ASP.NET, это может занять довольно много времени, поскольку ваши восстанавливающие пакеты перед каждой сборкой. Если вы действительно creative, вы можете выполнить script вместо этого, чтобы определить, если новый доступен пакет классов классов и запустите dotnet restore.

• Это самая большая боль. Каждый раз, когда вы вносите изменения в свою библиотеку классов, вы должны помнить о его создании, поскольку ваш веб-проект больше не имеет ссылки на проект, он не будет автоматически создавать библиотеки классов.

Ответ 3

Я сегодня борюсь с подобными ошибками по ссылке на весь день, после работы 3 дня для преобразования решения с RC1 на RC2. Вот некоторые из моих выводов, которые могут иметь отношение к этому вопросу:

• Добавление ссылки на проект путем редактирования project.json напрямую не сработало, потому что элемент itemGroup- > ProjectReference должен быть добавлен в файл xproj тоже, и это, похоже, происходит только при использовании ссылок → Добавить ссылку.. → Выберите проект.
• Названное имя проекта И его имя сборки ДОЛЖНЫ соответствовать (без пробелов) в RC2 (это не было проблемой в RC1).
• У меня были зависимости от сборки без привязки (добавлено с помощью кнопки "Обзор..." ), это не работало в RC2, и была показана следующая ошибка: ".Net Core-проекты поддерживают поддержку ссылок на сборки .NET Framework в этой версии. Чтобы ссылаться на другие сборки, они должны быть включены в пакет NuGet и ссылаться на этот пакет.". Моим решением для RC 2 было создание пакетов nuget для этих сборок и настройка частного сервера nuget: http://docs.nuget.org/Contribute/Ecosystem#nuget-server-project

BTW, я использую VS 2015 Update 2. Чтобы быть ясным, эти проблемы, вероятно, связаны с ограничениями/ошибками в VS 2015 Tooling/SDK Preview 1, а не с ASP Core 1.0 RC2.