Заставьте компилятор использовать ссылки только из установленных пакетов NuGet вместо локальных DDL

#c# #visual-studio #nuget #roslyn

Вопрос:

Можно ли указать компилятору не загружать локально установленные библиотеки DLL и использовать только ссылки, предоставленные установленными NuGet-пакетами?

На наших машинах разработчиков установлены различные фреймворки, которые отсутствуют в нашей CI-среде. Это часто приводит к сбою сборки и очень раздражает при исправлении.

Например, по ссылкам на мои проекты Microsoft.Office.Interop.Word , которые работают локально, потому что на моей машине установлен офисный пакет. Как только я запускаю сборку в CI, сборка завершается неудачно, потому что пакет office не установлен на наших агентах.

Обновить

Корень моей проблемы заключается в следующем. У меня есть некоторое устаревшее программное обеспечение, которое раньше не использовало пакеты NuGet. На местном уровне я могу создавать эти проекты без каких-либо проблем. Но как только я запускаю сборку CI, сборка завершается неудачно, так как некоторые ссылки не установлены в агенте. Затем мне нужно найти пакет NuGet, который может заменить локальную ссылку, и перенести изменения в наше репозиторий git.

Я хотел бы пропустить эту трудоемкую задачу по изменению ссылок, затем нажать и дождаться завершения сборки. Если бы была возможность указать компилятору не использовать локальные ссылки, я бы получил те же ошибки на своей локальной машине.

Комментарии:

1. Можете ли вы привести пример ссылки, о которой вы говорите, которая терпит неудачу? Обычно, если вы хотите указать компилятору использовать пакеты nuget, вы просто используете <PackageReference> csproj, и все готово; если вы используете другие виды ссылок: каковы они?

2. @MarcGravell Я добавил пример. Эта проблема в основном возникает только со старыми приложениями в нашем портфолио, так как новые проекты создаются только с использованием пакетов NuGet

3. @mamen что делает xml — элемент, который импортирует взаимодействие. Библиотека Word в вашем файле .csproj выглядит так?

4. В зависимости от масштаба вы можете удалить ссылку на сборку, а затем установить пакет NuGet.

5. Также зачем просто заменять их все пакетами NuGet за один раз? Я знаю, это больно, но это не то, что тебе нужно будет делать снова в будущем.

Ответ №1:

У меня есть некоторое устаревшее программное обеспечение, которое раньше не использовало пакеты NuGet. На местном уровне я могу создавать эти проекты без каких-либо проблем. Но как только я запускаю сборку CI, сборка завершается неудачно, так как некоторые ссылки не установлены в агенте.

Ваши проекты будут ссылаться на сборки из GAC или через COM.

Вы хотите запретить ссылаться на любую из них (кроме основных сборок, которые поставляются как часть вашей целевой платформы).

Для этого выполните поиск по всем файлам вашего проекта (т. е. .csproj файлам) в поисках любого из элементов типа <Reference> или <COMReference> . Любые из них, которые ссылаются на сборки, не относящиеся к фреймворку, должны быть удалены и преобразованы <PackageReference> вместо этого.

Под «сборкой рамок» я подразумеваю такие вещи, как System.Windows.Forms и так далее. Вещи, которые поставляются с .NET. Точный набор зависит от того, на какую целевую структуру вы ориентируетесь. Я предполагаю, что это какая-то версия .NET Framework. Если да, то, возможно, пока оставьте какие <Reference> -либо совпадающие элементы System.* .

Если у a <Reference> есть a HintPath , это довольно хороший признак того, что он также забирается локально с вашей машины и должен быть преобразован.

Комментарии:

1. Спасибо, это, кажется, лучший вариант для меня.

2. Рад слышать, что это звучит многообещающе. Как у тебя дела?

3. Я открыл все .csproj файлы и составил список ссылок, которые мне нужно заменить. Затем я заменил их все пакетами NuGet. Для следующего унаследованного проекта, который мне нужно интегрировать в наши системы CI/CD, я сделаю это с самого начала.