Reputation: 8202
So sometimes (oftentimes!) you want to target a specific .NET version (say 3.0), but then due to some .NET service packs you get into problems like:
Dispatcher.BeginInvoke(Delegate, Object[])
<-- this was added in 3.0 SP2 (3.0.30618 )System.Threading.WaitHandle.WaitOne(Int32)
<-- this was added in 3.5 SP1, 3.0 SP2, 2.0 SP2Now, these are detected by the JIT compiler, so building against .NET 3.0 in Visual Studio won't guarante it will run on .NET 3.0 only systems.
Short of
what's the best way to avoid against using extensions?
Thanks!
Upvotes: 15
Views: 598
Reputation: 6106
This capability is built into Visual Studio as of VS 2008 SP1 and is also available in FxCop 1.36. Take a look at David Kean's blog post for more details.
Upvotes: 4
Reputation: 11675
There was a way of telling windows which .Net version use. It is something like creating a file called dllhost.exe.config IN windows\system32 with xmllike :
<? xml version = "1.0" ?>
<configuration>
<startup>
<SupportedRuntime version = XXXXXX>
</startup>
</configuration>
See: http://msdn.microsoft.com/en-us/library/w4atty68.aspx
Upvotes: 2
Reputation: 31071
Microsoft tend to assume that, if you have .NET XXX installed, then you must be on the latest service pack because Windows Update will push them out to you as critical updates. I know it's a brittle assumption and sometimes breaks down, but that's what's supposed to happen.
Our products currently target .NET 3.5 SP1, and as such we would be astonished to find a target environment still running .NET 3.5 RTM.
Upvotes: 5
Reputation: 29579
Before sending out a release, compile your application with the appropriate version of Visual Studio that corresponds to the least-common denominator of your target userbase.
Just keep a virtual machine ready that has, say Visual Studio 2005 no SPs at hand, and compile the solution from there before deploying.
Upvotes: 1