检测.NET Framework 3.5 SP1依赖关系（cmp 3.5 w / o SP1） [英] Detect .NET Framework 3.5 SP1 Dependency (cmp. 3.5 w/o SP1)

问题描述

我在我的机器上使用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中不可用的函数或构造函数，代码将无法正常工作。

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.

到目前为止，我们已经完成了测试（在VM或单独的机器中），以查看应用程序是否中断，有时会断开我们已经使用了部分API，直到SP1才可用。问题是它只会在代码实际运行时（在运行时）中断，而不是加载程序集时才会中断。

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并尝试编译项目。
但是，我希望通过分析源代码或我们生成的程序集来帮助我检测到3.5 SP1的依赖关系（由于使用新的API或其他任何内容）。

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），让我们陷入困境。有关如何引用Service Pack版本中引入的API的更多详细信息，可能会泄漏到Visual Studio注意到的代码中，请参阅 Krzysztof 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有a 新规则来检测这些泄漏。不幸的是，当您定位到.NET Framework 3.5时，FxCop 1.36中的规则会被破坏。但是，David Kean描述了如何编辑一些XML配置文件到修复问题。我按照说明操作，FxCop现在检测到我对service pack 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.

这篇关于检测.NET Framework 3.5 SP1依赖关系（cmp 3.5 w / o SP1）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！