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?

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
Tom Tresansky
  • 19,364
  • 17
  • 93
  • 129
  • 3
    Where did the NET_2_0, NET_3_5 etc. constants come from? I can find plenty references to them in Mono docs, but nothing official at microsoft.com. – Tim Robinson Mar 07 '10 at 17:21
  • Tom, have you checked your csproj file to see if there was any additional includes or targets other than the standard Microsoft ones? This may be custom build functionality included in this project. – rh. Mar 07 '10 at 18:40

3 Answers3

3

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
  • 38,869
  • 30
  • 127
  • 202
  • 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 Mar 07 '10 at 17:38
  • 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 Mar 07 '10 at 18:01
  • Seems like we need to get away from this. Thanks! – Tom Tresansky Mar 07 '10 at 18:09
0

What's wrong with Environment.Version?

pdr
  • 6,372
  • 1
  • 29
  • 38
  • 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 Mar 07 '10 at 17:27
  • David, my project frequently used these for exactly that purpose. – Tom Tresansky Mar 07 '10 at 17:39
  • 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 Mar 07 '10 at 17:52
  • Using new features such as Linq does not work pre-.NET 3.0. So compile time option is the best way to switch between .NET 2.0 and 3.0+. Unfortunately, there are times when we are forced to target the .NET 2.0 framework, such as customer demand. It was nice when this was automatically done for us in Visual Studio. – TamusJRoyce Oct 26 '11 at 15:53
0
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
  • 5,675
  • 21
  • 29
  • Foxfire, my project's documentation contains a link to http://msdn.microsoft.com/en-us/library/system.reflection.assembly.imageruntimeversion.aspx which 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 Mar 07 '10 at 17:44
  • 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 Mar 07 '10 at 17:49