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