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.
If we use functions or constructors not available in 3.5 w/o SP1 the code will not work properly.
That is, I want to detect at compile time what would not work without 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.
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?
NET 3.5 is installed by looking at HKLM\Software\Microsoft\NET Framework Setup\NDP\v3. 5\Install, which is a DWORD value. If that value is present and set to 1, then that version of the Framework is installed. Look at HKLM\Software\Microsoft\NET Framework Setup\NDP\v3.
NET Framework 3.5 Service Pack 1 is a full cumulative update that contains many new features building incrementally upon . NET Framework 2.0, 3.0, 3.5, and includes cumulative servicing updates to the . NET Framework 2.0 and . NET Framework 3.0 subcomponents.
Here we show you how to solve this issue. First, you can check if the component is already installed on your device. Go to Control Panel > Programs > Turn Windows features on or off, verify if . NET Framework 3.5 checkbox is selected and then proceed with the software installation.
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.
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.
How about this? (multi-targetting rules for FxCop)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With