Является ли плохой практикой совместное использование одной и той же папки вывода сборки между проектами решения?

#.net #visual-studio #msbuild

Вопрос:

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

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

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

1. На самом деле это не очень специфично для msbuild; не предлагаю, чтобы это было перенесено, но было бы хорошо подходит для programmers.stackexchange.com например.

Ответ №1:

На мой взгляд, всегда лучше иметь отдельную папку сборки вывода для каждого проекта. Во-первых, чтобы избежать таких вещей, как перезапись, как вы сказали, а во-вторых, только из контекста, проекты следует рассматривать отдельно, будь то файлы конфигурации или сборки. Если позже у вас также появятся конвейеры CI/CD в сочетании со сборками, они также предоставляются отдельно, и с помощью сценариев вы можете соответствующим образом собрать необходимые конфигурации или также скопировать, например, статические файлы (например, сборки интерфейса Javascript) в соответствующую папку проекта, которая отвечает, например, за предоставление пользовательского интерфейса (например, через .NET ASP и статические файлы).

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

Ответ №2:

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