选择基于.Net Framework的哪个Service Pack进行构建

我在这里读过很多问题（和答案），这些问题听起来和这个问题类似，但最终都是关于针对不同的.Net主要版本构建的。不幸的是，我陷入了更深的困境

故事是这样的。我们的客户使用.Net framework的2.0版。只有2.0，根本没有服务包。我们的开发人员过去使用.NET2.0SP1，它工作得很好。现在，由于我们正在进行的其他项目，开发人员（包括我自己）更新到了.NET2.0SP2。这就是问题的根源。显然，凭借其无限的智慧，MS决定在不增加主要版本（比如2.1）的情况下更改/添加API到框架。因此，当您基于2.0构建时，它是基于2.0 SP2构建的（如果您安装了它），并且似乎没有办法对其进行配置。因此，开发人员现在可以编写代码，认为自己的目标是2.0，但这在客户机器上是行不通的

我们注意到某些构建（使用msbuild完成）在我们的测试盒上开始失败，但在开发人员的机器上工作正常。显然，因为测试盒是按照客户机的方式设置的，而且它们的旧框架缺少一些API。现在，构建场将安装更新版本的CLR（包括SpeService Pack和更高版本的主要修订版）来测试我们的所有项目，因此使用原始2.0中没有的API的构建将不再失败。。。这对于兼容性测试来说是个可怕的消息

所以我的问题是。如何根据特定CLR修订版（相同主版本）生成（使用msbuild）。如果做不到这一点，当特定项目使用与CLR的特定版本不兼容的功能时，如何确保VS2005抛出错误（将扳手插入齿轮，没有FxCop或类似的集成，只有基本的VS2005功能）

如果以上问题没有肯定的答案，我完全赞成寻找替代方案

---

谢谢。

除非您使用了新的API，否则升级到SP2不会产生任何影响。您在构建机器上看到了哪些故障

我同意，顺便说一句，他们不应该在不改变次要版本的情况下添加任何内容。然而，这是为了Vista，他们失去了理智

---

我猜。

我有；不幸的是，没有简单的解决办法。唯一的解决方案是1）希望来自service pack的更改不会影响您——有时会，有时不会——或者2）创建单独的生成机器，每个机器只安装了相应的service pack，然后在那里生成

问题是，开发人员（特别是新开发人员，或者正在从其他项目移植代码的开发人员）倾向于引入不兼容的API调用。现在，它对开发人员来说是完全透明的，如果不创建一个黑名单并让开发人员在添加内容时不断检查黑名单，就无法抓住自己。当然，如果您发现需要更新框架的SP，那么让您的客户也这样做是有意义的，否则，您将开发一个已知有缺陷的平台。也就是说，不是每个平台都有缺陷吗毕竟，升级是免费的（是的，我接受与执行升级相关的成本（如果您的基础设施没有部署解决方案）。此外，如果工作站没有收到此更新，那么还有什么没有收到，以及在支持已知的故障环境时浪费了多少额外的支持时间。再次回到我的第一条评论；）@Alex K:你有捕捉问题的完美技巧：使用连续集成，并以最低要求（.NET 2.0 RTM）在系统上部署构建。如果它无法构建，就责骂使用新API的开发人员。此外，我相信FxCop（代码分析）会发现这一点，至少对于一些服务包。@约翰，虽然我认为你在讨论中的第二个帖子是我可能会得到答案的结尾，但我不能投票回答，我认为你的OP不是一个很好的答案。很抱歉，如果看起来我没有确认您的回答。检查您的链接，我发现这是因为您使用的是AJAX控件工具包，您是根据3.5 SP1重新构建的，对吗？您是否将此报告为Connect（）上的错误。我知道Codeplex上报告了它，但Connect转到产品组，应该告诉他们为什么不更改SP中的继承层次结构。不，它来自我代码的另一部分；我刚刚将问题的解决方案发布到AJAX控制工具包bug报告中。至于报告给微软。。。如果我把它报告为一个bug，也许他们会在以后的版本中关注它，但是损害已经造成了。