tags:

views:

121

answers:

3

I'm building a C# class library, and using the beta 2 of Visual Web Developer/Visual C# 2010. I'm trying to save information about what version of .NET the library was built under. In the past, I was able to use this:

// What version of .net was it built under?
#if NET_1_0
        public const string NETFrameworkVersion = ".NET 1.0";
#elif NET_1_1
        public const string NETFrameworkVersion = ".NET 1.1";
#elif NET_2_0
        public const string NETFrameworkVersion = ".NET 2.0";
#elif NET_3_5
        public const string NETFrameworkVersion = ".NET 3.5";
#else
        public const string NETFrameworkVersion = ".NET version unknown";
#endif

So I figured I could just add:

#elif NET_4_0
        public const string NETFrameworkVersion = ".NET 4.0";

Now, in Project->Properties, my target Framework is ".NET Framework 4". If I check:

Assembly.GetExecutingAssembly().ImageRuntimeVersion

I can see my runtime version is v4.0.21006 (so I know I have .NET 4.0 installed on my CPU). I naturally expect to see that my NETFrameworkVersion variable holds ".NET 4.0". It does not. It holds ".NET version unknown".

So my question is, why is NET_4_0 not defined? Did the naming convention change? Is there some simple other way to determine .NET framework build version in versions > 3.5?

+3  A: 

The NET_x_y version number manafests you speak of were never part of an official spec, and it would appear Microsoft has discontinued them.

David Pfeffer
Hmmm, this might be the case. I could find very few references to them when I was Googling. Maybe a previous developer on my project just stumbled across this and it worked up until now.
Tom Tresansky
Also, the flag used to be set by Visual Studio via a command line argument to the compiler; it was not set by the compiler itself. This is dangerous because if you ever change build methodology to NAnt or similar, you would have to emulate Visual Studio's behavior.
David Pfeffer
Seems like we need to get away from this. Thanks!
Tom Tresansky
A: 

What's wrong with Environment.Version?

pdr
He's most likely looking to use environment specific functionality at compile time... i.e. call a method that doesn't exist in certain Frameworks. You'd have to use reflection to do this at runtime.
David Pfeffer
David, my project frequently used these for exactly that purpose.
Tom Tresansky
Also: "Unfortunately, this tells you the .NET CLR (runtime library) version, not the version of the .NET Framework. These two version numbers are not always the same; in particular, the .NET Framework 3.0 and 3.5 both use the .NET CLR 2.0."Via: http://stackoverflow.com/questions/37468/how-to-determine-the-installed-asp-net-version-of-host-from-a-web-page/37530#37530
Tom Tresansky
A: 
Assembly.ImageRuntimeVersion

contains which runtime version an assembly was compiled against, so there is no need for that ugly hack you are doing with the preprocessor directives at all.

Foxfire
Foxfire, my project's documentation contains a link to http://msdn.microsoft.com/en-us/library/system.reflection.assembly.imageruntimeversion.aspxwhich contains the note:By default, ImageRuntimeVersion is set to the version of the CLR used to build the assembly. However, it might have been set to another value at compile time. I think this HOWEVER is why one reason we have tried to get the version in some other manner, though I may be wrong.The other reason is for conditional compilation of functions which use methods that only exist in certain versions.
Tom Tresansky
Also of note: apparently Assembly.ImageRuntimeVersion property was not available under .NET Framework 1.0. Not that I think anyone involved with the project would still be using 1.0...or that we still officially support it...
Tom Tresansky