Azure DevOps, как построить проект со ссылками на другой проект в другом решении - PullRequest
0 голосов
/ 18 июня 2019

Как видно из заголовка, каждый из моих Решений содержит проекты, основанные на другом решении, например,

Раствор А

Проект АА Project AB Проект AC Решение B (Содержит только библиотеку классов, в которой есть папка, в которую я помещаю пользовательские файлы appsettings.json. Она не может быть построена на DevOps, поскольку она не считается проектом)

Проект BA Решение AA и AC ссылки BA. В .csproj проекта AA и AC есть HintPath, показывающий местоположение BA

Когда я компилирую в своей локальной среде, все в порядке, и ему удается скомпилировать и запустить правильно.

Я использую GitHub в качестве репозитория, и когда я обращаюсь к нему из Azure DevOps и пытаюсь создать свое решение A, я получаю следующие ошибки:

D: \ a_tool \ Dotnet \ SDK \ 2.2.103 \ Microsoft.Common.CurrentVersion.targets (2110,5): предупреждение MSB3245: не удалось разрешить эту ссылку. Не удалось найти сборка "CentralApplicationSettings". Убедитесь, что сборка существует на диске. Если эта ссылка требуется вашим кодом, Вы можете получить ошибки компиляции. [D: \ а \ 1 \ s \ ManagementStudio.ClassLibrary \ ManagementStudio.ClassLibrary.csproj] D: \ a_tool \ Dotnet \ SDK \ 2.2.103 \ Microsoft.Common.CurrentVersion.targets (2110,5): предупреждение MSB3245: не удалось разрешить эту ссылку. Не удалось найти сборка "CentralApplicationSettings". Убедитесь, что сборка существует на диске. Если эта ссылка требуется вашим кодом, Вы можете получить ошибки компиляции. [D: \ а \ 1 \ s \ ManagementStudio.Data \ ManagementStudio.Data.csproj]

В основном говорится, что он не может найти требуемые ссылки из GitHub, и это имеет смысл, потому что GitHub и DevOps не имеют похожую структуру папок, поэтому HintPath не будет иметь смысла для компилятора.

Мне рекомендовали сменить Решение B на пакет NuGet, но проблема в том, что мне нужно будет помещать туда файлы своих пользовательских настроек каждый раз, когда я развертываю новое Решение, так что об этом не может быть и речи.

Есть ли другой способ, с помощью которого я могу построить свое решение A на DevOps Azure, не превращая его в пакет NuGet?

Решение A похоже на приложение для управления учетными записями, поэтому я собираюсь развернуть его вместе с другим приложением более специального назначения.

EDIT:

В решении B есть папка, в которую я помещаю мои пользовательские файлы appsettings.json в папку, чтобы другие развернутые приложения могли получить к ним доступ. Это как библиотека appsettings.

Если я сделаю пакет NuGet, я не смогу скопировать туда файл appsettings.json.

1 Ответ

1 голос
/ 18 июня 2019

Создайте другое решение в пакеты и отправьте их в ленту новостей Nuget и используйте эту ленту при восстановлении во втором проекте

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...