在 Visual Studio C# 解决方案中，所有项目共享相同的输出路径有什么缺点吗？我想这样做是因为我们使用依赖注入并且文件不会自动复制（因为它们没有被引用）。这会给我带来什么问题吗？
（这与：C# - Copy dlls to the exe output directory when using dependency injection with no references?有关）
【问题讨论】：
标签： c# .net visual-studio
我们正在我们当前的项目中这样做。我们有大约 30 个项目输出到同一个 bin 文件夹，我们没有遇到任何问题。
【讨论】：
如果您有两个不同的项目，取决于同一程序集的不同版本，则可能会出现问题。如果我的项目 A 取决于 X.dll 版本 1，项目 B 取决于 X.dll 版本 2，您将无法将两个版本的 X.dll 放入同一个输出文件夹（无需重命名） .诚然，这些可能性不高，但也不为零。
【讨论】：
拥有多个项目的目的是生成多个程序集。程序集是 .Net 中的一种部署机制。如果您总是计划将所有输出 dll 捆绑到一个包中，那么我认为这种方法没有缺点。
但是，如果出于某种原因，您计划将程序集 A、B、C 与程序集 D、E、F 分开部署，则保持输出目录分开将确保正确的程序集和仅其依赖项在输出中文件夹。然后编写一个脚本将这些程序集正确捆绑到您想要的正确包装中会更容易。
【讨论】：
通常不是缺点，我发现为我的目标程序集提供一个输出位置非常有益。当 VS 通过确定依赖项对项目进行编译排序时，它将覆盖已在构建顺序中较早构建的已编译程序集的现有实例。
让我不必在构建所有内容时四处寻找已编译的程序集。
您可能会遇到问题的一些情况是，如果您有两个项目引用了不同版本的外部程序集，您最终可能会得到一个捆绑的程序集而没有不正确版本的依赖项...
【讨论】：
如果您计划以不同方式（核心包与附加组件等）部署程序集，您可能会遇到与 TeamBuild 或您正在使用的任何自动构建过程有关的问题
您自定义构建脚本的方式会有所不同（不一定是不利的），具体取决于您对 csproj 文件进行了多少自定义。
【讨论】：
这种方法的一大缺点是，如果您的启动项目包含对其他项目在构建期间引用的任何 dll 的引用，即使 copy local = false，您通常也会遇到访问冲突问题。我现在每天都遇到这个问题。我建议有一个包含所有需要参考的项目，并为这些参考复制 local = true。这也有助于制作安装程序。
【讨论】：