Is there a quick way to test whether a given dll contains code that can be run only with .net 4.5 without actually trying to load it by any CLR?
Background: I have a DLL which I am compiling to the 4.0 target but with the .net 4.5 (vs 2012) toolset. My running environment does not have 4.5 installed. I am using the AsyncTargetingPack to write async code, and targeting the code to .net 4.0.
I want to make sure that I didn’t, by accident, screw something up that will cause my DLL to reference some .net 4.5 only classes/namespaces.
This has never been possible, except when there’s a major CLR version change. Which worked from .NET 1.0 to 1.1, 1.1 to 2.0 and 3.5 to 4.0. In-between versions had no CLR version change, neither is there one from 4.0 to 4.5
This caused a pretty infamous problem with the WaitHandle.WaitOne(int) method, an overload that was added to the .NET 2.0 SP1 version of mscorlib. Without a corresponding change the [AssemblyVersion], still 2.0.0.0. So programmers unwittingly used the overload and had their code bomb on a machine that didn’t have the service pack installed.
Microsoft fixed that problem in .NET 4, the reference assemblies are no longer a copy of the runtime assemblies. They just contain the metadata, no IL. Which in turned allowed them to make changes the public classes without fearing that they’ll break anything, the reference assemblies were not updated. Lots of updates to .NET 4 have been shipped, never heard of an accident.
Same thing with .NET 4 to 4.5. When you use the 4.0 reference assemblies, you can be sure you don’t accidentally use a 4.5 specific class or method. Actually using a 4.5 added feature requires compiling with the 4.5 reference assemblies.