Влияние добавления ссылки dll против ссылки проекта
Есть ли влияние времени сборки? У нас есть около 30 проектов в нашем решении.Net, и они делятся общими проектами по ссылке проекта. Вместо этого я думаю перейти на dll-ссылку, чтобы увидеть, есть ли прирост производительности сборки. У кого-нибудь был опыт в подобных направлениях? Пожалуйста, поделитесь своими мыслями.
2 ответа
Да, это может оказать огромное влияние в зависимости от того, как настроен ваш CI.
Решение этой проблемы состоит в том, чтобы сгруппировать логические разделы вашего приложения (доступ к данным, презентация и т. Д.) В отдельные решения и превратить их в пакеты NuGet. Я добился большого успеха, объединив TFS build, Release Management и NuGet для автоматизации непрерывной доставки пакетов NuGet от "предварительной версии" до "стабильной".
Вы можете также упаковать файлы PDB для целей отладки, а использование NuGet также помогает в совместном использовании кода между различными разнородными проектами. Если Project A использует версию 1.2.3 пакета X, но вы обновили пакет X до версии 2.0.0 для проекта B, Project A может с радостью продолжать использовать версию 1.2.3.
Одна вещь, которую нужно иметь в виду, когда делите раскол, как это:
const переменные заменяются во время компиляции во всех сборках с литеральным значением. Если вы измените const значение в сборке A, а сборка B ссылается на const значение, значение не изменится в сборке B, если вы не перекомпилируете его. Вы можете избежать этого, используя readonly поля вместо const,
Я не знаю, почему ссылки на DLL экономят ваше время, единственная дополнительная плата за ссылки на проекты - это решение дерева зависимостей, которое вы определенно хотите сделать.
В противном случае, если вы не будете осторожны, у вас получится проект, который ломается каждый раз, когда вы перестраиваете, и для нормальной работы требуется пара обычных сборок.