5

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

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

4

3 回答 3

4

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

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

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

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

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

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

于 2009-01-28T16:22:34.787 回答
1

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

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

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

您也可以按照ShuggyCoUk 的建议选择将 ..\..\Build 分成 ..\..\Release 和 ..\..\Debug 。

于 2009-02-02T16:32:44.040 回答
0

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

于 2009-01-28T15:36:53.160 回答