Разрешение разрешения пространства имен с NuGet и моно - PullRequest
Новая
       18

Разрешение разрешения пространства имен с NuGet и моно

0 голосов
/ 09 июня 2019

Вопрос : можно ли запустить mono msbuild и заставить его использовать определенные каталоги в качестве определенных пространств имен.Например, пространство имен DevExpress может быть сопоставлено с каталогом /app/MyApp/DevExpress.Или, если это не вариант, как мы можем информировать наш проект о недавно установленных пакетах с NuGet?

Для некоторого контекста: несколько лет назад мы унаследовали (очень) устаревший стекприложений, в том числе .NET-приложений, использующих DevExpress для создания набора из 3 приложений, используемых моим клиентом для запуска его событий.Мы не знаем .NET (клиент был предупрежден и принял это, желая сосредоточиться на своих веб-приложениях), но нам удалось стабилизировать его и уже несколько лет компилировать его с помощью PowerShell и msbuild.

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

Проект не *Изначально 1018 * использовал NuGet, но для автоматизации всего этого мы подумали, что можем установить контейнер Docker с моно, использовать nuget для извлечения зависимостей и затем скомпилировать.

К сожалению, в настоящее время мы сталкиваемся с проблемой с разрешения пространства именне похоже на работу. 

"/app/MyApp/MyApp.csproj" (default target) (1) ->
"/app/DataAccessLayer/DataAccessLayer.csproj" (default target) (3:2) ->
(CoreCompile target) -> 
  xp Server Objects/dbo_CITY.cs(6,7): error CS0246: The type or namespace name 'DevExpress' could not be found (are you missing a using directive or an assembly reference?) [/app/DataAccessLayer/DataAccessLayer.csproj]

Редактировать : я отметил ответ zivkan как правильный, поскольку, хотя он не дал мне решения, я мог пойти и реализовать, он далЯ (и, надеюсь, этот вопрос) много полезной информации, чтобы двигаться вперед.

1 Ответ

0 голосов
/ 10 июня 2019

Построение .NET проектов не работает так (посмотрите путь x для пространства имен y).Вместо этого компилятору предоставляется список библиотек для ссылок, в дополнение к исходным файлам, и компилятор сканирует метаданные всех ссылок, чтобы увидеть, какие пространства имен / классы доступны.Я считаю, что Java работает почти так же, с jar-файлами, хотя я никогда не делал ничего серьезного в Java.

Обычно это работает так: вы используете Visual Studio (или другую IDE, которая знает о .NET).) и использовать встроенные инструменты для добавления пакета NuGet в проект, как показано в установке пакета с документами быстрого запуска Visual Studio .Если вы используете .NET Core, вы можете использовать dotnet add package <package id из командной строки.Это изменяет файл проекта (.csproj), поэтому система сборки знает об этом (если вы используете PackageReference, тогда достаточно просто редактировать csproj непосредственно, но если вы используете packages.config, вам абсолютно необходимы инструменты, чтобы сделать это дляyou).

Затем процесс сборки CI сначала загружает nuget.exe, затем запускает nuget.exe restore, затем выполняет сборку проекта или при использовании .NET Core запускают dotnet restore и dotnet build (с тех пор.Восстановление NET Core 2.0 происходит автоматически как часть сборки, поэтому больше нет необходимости делать отдельные шаги).Это также еще одно преимущество использования .NET Core, больше не нужно загружать nuget.exe просто для восстановления, наконец, NuGet встроен в систему сборки (технически я думаю, что проекты не в стиле SDK могут делать это тоже с PackageReference и msbuild -restore).

Тот факт, что вы получаете сообщение об ошибке по отсутствующему пространству имен, говорит мне, возможно, что вы не запускали nuget restore на компьютере CI, или, возможно, вы не использовали NuGet в обычном режиме.способ.

...