Что вы делаете со ссылками при выгрузке проекта в Visual Studio?

Question

Когда вы выгружаете проект в Visual Studio, любые ссылающиеся проекты получают предупреждающие треугольники при обращении к выгруженному проекту. Я написал себе макрос, чтобы делать умные вещи (обнаруживать добавление / удаление проекта и преобразовывать любые ссылки из зависимости от файла / проекта), но я не могу поверить, что я не упускаю ничего более простого. Чем может быть полезна функция unload, если мне приходится обходить вручную изменяющиеся ссылки (и это нарушает парадигму групповой разработки «личные решения / общие проекты»).

(Этот вопрос относится к ответам на этот вопрос о структурировании больших решений в Visual Studio - в некоторых ответах упоминалось, что есть решения с большим количеством проектов, но «выгрузка» неиспользуемых проектов для повышения производительности.)

Answer 1

У меня только что был момент eureka, читающий документ MSDN по структурированию решений и проектов.

Чего я не заметил, так это того, что в многопроектном решении контекстное меню в обозревателе решений предлагает всплывающее окно «Зависимости проекта». Здесь вы можете определить зависимости проекта вручную, если вы не определили их по ссылкам между проектами.

См. здесь (ссылка MSDN, поэтому самоуничтожится через несколько недель)

Answer 2

Каковы преимущества наличия проектов в одном решении, если вы используете ссылки на файлы?

Если ваш app.exe использует utils.dll и вы измените код на utils.dll, тогда, если он находится в одном и том же решении, VS заметит зависимость и перекомпилирует оба. Если это не решение, вы должны будете выпрыгнуть, перекомпилировать utils.dll отдельно, затем вернуться обратно и перекомпилировать app.exe.

Это становится более или менее важным в зависимости от того, сколько других dll ссылается на ваш exe, и как часто они меняются (в командной среде в моем опыте часто менялись dll). Есть также побочный эффект, что если у вас есть 100 проектов в VS, потребуется много времени, чтобы обработать их все, чтобы выяснить, нужно ли им перекомпилировать или нет.

Answer 3

Выгрузка проектов подразумевается как временное действие, поэтому вы можете редактировать фактический файл проекта в формате XML (текст). Если вы хотите полностью удалить проект из своего решения, вам следует использовать опцию меню «Удалить», которая позаботится об удалении любых ссылок на этот проект.

Одним из преимуществ использования ссылок на проекты является то, что он позволяет легко отлаживать код. Он также автоматически гарантирует, что вы используете правильную сборку конфигурации (т. Е. Если вы собираете в режиме «Отладка», он будет использовать отладочную версию сборки). При этом вы теряете определенную определенность в отношении того, какую версию / сборку зависимого проекта вы выберете - ссылки на проекты означают, что вы всегда используете самую последнюю версию.

Да, для того чтобы Visual Studio мог определить зависимости сборки, он должен иметь возможность видеть и создавать все проекты, которые означают ссылки на проекты.

Answer 4

Для моих проектов я создаю папку assemblies, в которую проекты автоматически копируются из заданного местоположения, в которое копируются другие проекты.

Пост-сборка для проекта сборочной сборки:

if not exist "C:\builds\Project1" md "C:\builds\Project1\"
copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"

Предварительная сборка для ссылок на проекты:

если существует "c: \ builds \ Project1 \" copy "c: \ builds \ Project1 *. *" "$ (ProjectDir) сборки"

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