Question

我发现，如果你没有在任何地方启用“copy local”，那么很多项目的C＃解决方案的构建时间会快得多。我做了一些测试，似乎（至少我们的解决方案）我们可以通过删除“复制本地”来增加构建时间2-3倍。这可能意味着我们必须将库存储在一些公共目录中。

任何建议/最佳实践如何实现这一目标？请注意，我想保留对项目的引用，而不是DLL。

Answer 1

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

我们将每个项目中的引用路径设置为相应的Debug或Release目录（此设置保留在用户文件中，因为它是绝对引用而不是相对引用）

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

这可以通过命令行（使用MSBuild）在IDE模仿脚本构建中进行处理和手动构建

不用于部署的测试项目不会将其输出定向到集中的Debug | Release目录，它们只使用标准的默认位置（并使用copy local来避免锁定问题）

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

Answer 2

如果您的应用程序分布在各种解决方案中，我建议构建到.. \ .. \ Build。（如果你只有一个解决方案，你可以考虑.. \ Build。）默认情况下，Visual Studio会在它的输出文件夹中选择参考文件。但是，在使用MSBuild构建不使用VS时，必须将构建文件夹添加为引用路径，如下例所示：

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

这个例子也让我接受了第二个论点。我不认为你应该使用你的构建文件夹作为库文件夹，因为这可能导致单个项目错误地覆盖库程序集，例如通过使用复制本地。你应该严格控制你的库版本，所以我建议你把它分开。（开发人员需要在VS中添加此路径作为参考路径。）

您也可以选择将.. \ .. \ Build分隔为.. \ .. \ Release和.. \ .. \ Debug为suggested by ShuggyCoUk。

Answer 3

我喜欢在基于Unix的系统中常见的顶级Bin Lib文件夹设置，顺便转移到这种类型的系统也将使您的发布工程师的生活更加轻松。只需从一个文件夹中提取每个内容即可简化安装程序创建。然后Dll会进入bin ..

优化Visual Studio解决方案构建 - 放置DLL文件的位置？

3 个答案: