我使用的是3.5 SP1我的机器上，而我们的客户目前使用的3.5不带SP1。 我不知道任何方式在VS2008为目标的解决方案或项目，以3.5不带SP1中，只有3.5 SP1的我已经安装了。

I'm using 3.5 SP1 on my machine, while our customers currently use 3.5 without SP1. I don't know any way in VS2008 to target the solution or project to 3.5 without SP1, only the 3.5 with SP1 I have installed.

如果我们使用的功能或构造在3.5不可用W / O型SP1中的code将无法正常工作。

If we use functions or constructors not available in 3.5 w/o SP1 the code will not work properly.

这就是我想检测位于编译时间不带SP1什么是行不通的。

That is, I want to detect at compile time what would not work without SP1.

到目前为止，我们已经完成测试后（在虚拟​​机或单独的机器），如果申请休息，以看到的，它有时会打破的时候，我们使用没有用，直到SP1的API的一部分。的问题是，它仅打破时code实际运行（运行时），而不是当该组件被加载

So far we have done testing (in a VM or separate machine) to see if the application breaks, and it does break sometimes when we've used parts of the API not available until SP1. The problem is that it only breaks when the code actually runs (at runtime), not when the assembly is loaded.

一个解决办法是有一个机器VS2008 W / O SP1并尝试编译该项目。 不过，我想preFER一些工具来帮我检测依赖于3.5 SP1（由于使用新的API，或者别的什么），要么通过分析源$ C ​​$ C，或者我们生产的组件。

One solution would be to have a machine with VS2008 w/o SP1 and try to compile the project. However I'd prefer some tool to help me detect a dependency to 3.5 SP1 (due to use of new API, or whatever), either by analyzing the source code, or the assemblies we produce.

我的谷歌的力量还不够强大的这个问题，任何提示？

My google powers has not been strong enough with this question, any hints?

推荐答案

我有同样的问题，我找到了解决办法。对于我们的应用程序，它是让我们在患难中随时调用System.Threading.WaitHandle.WaitOne（Int32）已。有关这是在服务包版本中引入引用的API怎么能漏到code没有Visual Studio中注意到更多详细信息，请参阅的克日什托夫·Cwalina的帖子。

I just had the same problem, and I found a solution. For our application, it was a call to System.Threading.WaitHandle.WaitOne(Int32) that got us in trouble. For more details on how references to API's that were introduced in service pack releases can leak into your code without Visual Studio noticing, see Krzysztof Cwalina's post.

好消息是，作为Marc提到被他的回答，FxCop的有新规则检测这些泄漏。坏消息是，该规则中的FxCop 1.36被打破，你的目标的.NET Framework 3.5。不过，大卫·基恩介绍如何编辑几个XML配置文件解决问题。我跟着指示，和现在的FxCop检测我提到的服务包的API。

The good news is that, as Marc mentioned is his answer, FxCop has a new rule that detects these leaks. The bad news is that the rule is broken in FxCop 1.36 when you target .NET Framework 3.5. However, David Kean describes how to edit a couple of XML configuration files to fix the problem. I followed the instructions, and FxCop now detects my references to service pack API's.