优化Visual Studio解决方案构建 - DLL文件放在哪里？

Question

我发现，如果你在所有地方都不启用“复制本地”选项，那么具有多个项目的C#解决方案的构建时间会大大缩短。我进行了一些测试，似乎（至少对于我们的解决方案）只需删除“Copy local”即可将构建时间提高2-3倍。这可能意味着我们必须将库存储在某个公共目录中。

有什么建议/最佳实践可以实现这一点吗？请注意，我希望保留对项目的引用，而不是对DLL的引用。

- bh213

Answer 1

我们将项目的输出目录重新定向为../../Debug（或../../Release），我们的库也放置在这些目录中。

我们根据需要将每个项目中的引用路径设置为相应的Debug或Release目录（由于这是绝对而不是相对引用，因此该设置会保留在用户文件中）。

我们将项目引用保留为项目引用，所有dll引用都具有复制本地false和特定版本false，除非它们是我们知道将在所有部署机器上的GAC中的系统级dll。

这样做效果很好，IDE中的手动构建与使用MSBuild的命令行脚本构建相似。

不用于部署的测试项目不会将其输出直接指向集中的Debug | Release目录，它们只使用标准默认位置（并使用复制本地以避免锁定问题）。

自动化构建过程可以通过替换Debug和Release目录中的dll来更改库版本。

- ShuggyCoUk

Answer 2

如果你的应用程序分布在多个解决方案中，我建议构建到..\..\Build目录下。（如果你只有一个解决方案，可以考虑..\Build目录。）Visual Studio默认会在输出文件夹中获取引用文件。然而，当使用MSBuild在没有Visual Studio的情况下进行构建时，你必须将构建文件夹添加为引用路径，如下面的示例所示：

  <Target Name="BuildApp">
    <MSBuild
        Projects="@(ProjectReference)"
        Targets="Rebuild"
        Properties="ReferencePath=..\..\Build;$(LibraryFolder)" >
    </MSBuild>
    <OnError ExecuteTargets="BuildFailed" />
  </Target>

这个例子也提出了我的第二个论点。我认为你不应该将你的生成文件夹作为库文件夹，因为这可能会导致个别项目错误地覆盖库程序集，例如通过使用复制本地文件。你应该严格控制你的库版本，所以我建议你保持分离。（开发人员需要在VS中添加此路径作为引用路径。）

你还可以选择将..\..\Build分成..\..\Release和..\..\Debug，就像由ShuggyCoUk建议的那样。

- Magnus Akselvoll

Answer 3

我喜欢在基于Unix的系统中常见的顶级Bin Lib文件夹设置，顺便说一句，转移到这种类型的系统也会使您的发布工程师的工作更加轻松。只需从一个文件夹中提取所有内容，就可以大大简化安装程序的创建。Dll文件将放在bin中。

- Alex