解决方案中的每个 .Net 项目是否应该有自己的 OutputFolder？答案

【问题标题】：Should each .Net Project in Solution have it´s own OutputFolder or not?解决方案中的每个 .Net 项目是否应该有自己的 OutputFolder？
【发布时间】：2020-03-04 12:20:22
【问题描述】：

我有大约 50 个项目的解决方案。

Visual Studio 的默认行为是将每个项目构建到项目子文件夹 bin/debug 和 bin/release。

在我的公司里，所有项目都应该在一个共同的输出目录中结束。优点应该是不经常复制文件。这是在 .csproj 文件中定义 <OutputDirectory> 完成的。

检查构建输出向我显示了同一文件的许多删除和副本。所以我认为复制数量没有优势。

那么共享输出目录还有其他好处吗？有没有我还没有注意到的问题？处理此问题的最佳做法是什么？

感谢您的帮助：D

【问题讨论】：

这种问题通常是基于意见的
But it is possible to change this and build all projects into a shared folder ← 是的，但也许最好详细说明为什么你想这样做。你想解决什么问题？
@PavelAnikhouski 我的目的不是征求意见。我想在我的公司里争论激烈的利弊。
@R00st3r IMO，最好在softwareengineering.stackexchange.com上提问

标签： c# .net visual-studio csproj

【解决方案1】：

您只需使用 MSBuild 开关 --output 并在构建项目/解决方案时为所有输出指定一个文件夹即可完成此操作。所有依赖项目等都将被构建并复制到一个输出文件夹中。

我认为“减少被复制的文件数量”并不特别重要——硬盘每天都在复制文件。打包发布时输出到一个文件夹会有好处；我们的 Jenkins 构建服务器将所有文件捆绑到一个文件夹中，然后将它们放入包 (zip) 文件中以供 Octopus 部署

您需要小心，因为不同的项目可能依赖于同一个 DLL 的不同版本，并且通过将所有文件混合在一个文件夹中，相同名称（但不同版本）的 DLL 会覆盖每个其他。然后，您可能会遇到应用无法加载的情况，因为它正在尝试查找 XYZ DLL 版本 1.0，而其他一些项目引用了 1.1 版本，并且因为该项目稍后构建，所以它是 1.1 版本的 DLL最终在文件夹中。然后，您可能会遇到运行时错误，指示“找到的程序集的清单定义与程序集引用不匹配” - 它说“我正在寻找 1.0，我找到了一个名称正确的 DLL，但我找到的版本是 1.1”

这通常可以通过绑定重定向来解决，但不能 100% 保证未来版本的 DLL 向后兼容早期版本。如果您将所有 DLL 安排复制到一个文件夹中，那么当 DLL 版本与您的预期不同步时，您就在为自己创建一个彩票，以确定生产中是否会中断

如果您的公司运行使用本地复制的 DLL 版本的构建和部署过程，那么他们可能会坚持将所有 DLL 复制到一个文件夹以证明该应用程序可以在生产环境中运行 - 这是一个更好的理由（即为您安排一种方法来破坏开发服务器，以便您可以在投入生产之前查看并修复由 DLL 版本引起的问题）而不是“因为我们不希望硬盘厌倦复制额外的文件”

【讨论】：

【解决方案2】：

如果你坚持这样做。你可以

右键单击您的项目
选择“属性”=>“构建事件”=>“构建后事件命令行”
把 xcopy "$(ProjectDir)\bing\debug{yourprojectdll}" "{path to shared folder}" /Y /I /R

【讨论】：

我在构建到共享文件夹时没有问题（通过在 csproj 中设置 OutputPath 来完成），但我真的不知道这样做的利弊是什么。跨度>
拥有共享文件夹的优点是您无需将项目添加到解决方案中。您只需在共享文件夹中添加对项目 DLL 的引用。这可以在开发时为您节省大量时间。由于您不需要重建引用的项目（如果您引用 DLL）。