假设我有“构建服务器”和“开发机器”，它们都具有以下特征
我也从Eric Lippert's blog了解了以下关于C＃编译器的内容（我正在使用.NET，但可以询问任何静态语言构建过程的问题）
了解这一切。
如果我在构建服务器上构建源代码并获取一组我称之为server binaries的DLL和可执行文件
在我的开发机器上重建二进制文件是不是多余的，即构建local binaries
server binaries和local binaries不是彼此有效的替代品。
如果是这样，我可以复制所有server binaries ...但是local binaries已经消失的地方并将其视为我自己构建它们的想法。
显然，在只有1台开发机器的情况下，这似乎是不必要的，但如果我有n dev机器，我只需要构建一次，而不是n次。
我的逻辑是否有明显的缺点？这是.Net商店的常见做法吗？
答案 0 :(得分：0)
原则上是的，在您的机器上重建它们是多余的。但是你的问题不够具体，而且有多种可能的情景会产生不同的答案。
例如，如果你有基本的实用程序库，它们不经常更改并且保存在单独的解决方案中，那么这些是服务器构建它们然后被这样使用的明显候选者。但请记住，简单地复制二进制文件可能会很乏味且容易出错。每次更改代码时都必须这样做。你必须为它编写一个脚本。如果需要调试功能，还必须复制pdb文件并在开发机器上具有相同的源代码。在这种情况下，让NuGet为您管理这个可能很方便。另一种情况是这样的：如果整个项目非常大但模块化足够，以便单个开发人员或他们的团队可以在项目的单独部分工作，而不需要其余部分的完整来源。如果他们不必费心去构建他们不需要处理的项目部分，他们将获得时间，但只能从服务器中提取工作版本。
另一种典型情况是，您有一个解决方案，其中包含一组逻辑上属于一起的项目。像主要的ui项目一样，具有应用逻辑的基础项目，插件项目等。虽然原则上也可以让服务器为你构建其中的一些，这根本没有意义，并且完全不实用（并注意到这里的一些缺点也可能适用于上述情况，因为有时在一个简单的实用程序库和许多项目严重依赖的东西之间没有明确的明确界限：在修改源代码之后，你必须将更改推送到服务器，然后等待它构建，然后复制结果。这是浪费时间。特别是因为你的服务器可能需要很长时间来生成构建结果，因为它在所有可能的配置中构建/测试所有内容。此外，默认情况下，VS将覆盖您刚刚复制的二进制文件，因此您必须卸载项目或找出其他方法使其不这样做。