Detect CLR Version at Compile Time
-
Is there any equivalent of the _MFC_VER macro for the C# preprocessor that allows the user to detect the CLR version at compile time? I saw something like _CLR_VER in the 2005 C++ docs, but nothing for VB.net, C# or C++ for the .NET 1.0, 1.1 versions. ( I am using C# 2003 latest service packs.) ............................. There's nothing like the sound of incoming rifle and mortar rounds to cure the blues. No matter how down you are, you take an active and immediate interest in life. Fiat justitia, et ruat cælum
-
Is there any equivalent of the _MFC_VER macro for the C# preprocessor that allows the user to detect the CLR version at compile time? I saw something like _CLR_VER in the 2005 C++ docs, but nothing for VB.net, C# or C++ for the .NET 1.0, 1.1 versions. ( I am using C# 2003 latest service packs.) ............................. There's nothing like the sound of incoming rifle and mortar rounds to cure the blues. No matter how down you are, you take an active and immediate interest in life. Fiat justitia, et ruat cælum
No, there isn't. If you using C# 2003, you'll be compiling using the .NET Framework 1.1. VS.NET 2003 will NOT compile using 1.0 or 2.0 of the .NET Framework. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Is there any equivalent of the _MFC_VER macro for the C# preprocessor that allows the user to detect the CLR version at compile time? I saw something like _CLR_VER in the 2005 C++ docs, but nothing for VB.net, C# or C++ for the .NET 1.0, 1.1 versions. ( I am using C# 2003 latest service packs.) ............................. There's nothing like the sound of incoming rifle and mortar rounds to cure the blues. No matter how down you are, you take an active and immediate interest in life. Fiat justitia, et ruat cælum
There isn't. Java and .Net have been gravitating away from the concept of a "pre-compile" step so there is no "preprocessor" to mess with. I believe ultimately this is a good thing since it leads to cleaner, far more readible code. More to the point, why do you need to know, at compile time, what version of the CLR is available? You need to remember that a machine might have multiple versions (if not multiple implementations) of CLR available to run against. What would one do with such information in any C# code anyway? Versioning is handled by attributes and metadata where the compiler doesn't care (beyond generating correct IL).
-
There isn't. Java and .Net have been gravitating away from the concept of a "pre-compile" step so there is no "preprocessor" to mess with. I believe ultimately this is a good thing since it leads to cleaner, far more readible code. More to the point, why do you need to know, at compile time, what version of the CLR is available? You need to remember that a machine might have multiple versions (if not multiple implementations) of CLR available to run against. What would one do with such information in any C# code anyway? Versioning is handled by attributes and metadata where the compiler doesn't care (beyond generating correct IL).
I was concerned with the availability of obsolete functions or methods from one version of the CLR to another. With a CLR version compile time symbol definition I hoped to avoid all those obsolete methods messages. I will have to perform run-time detection of the CLR, but was hoping to use a ConditionalAttribute with the CLR version for source I might distribute that would work on 1.1 or 2.0 of the CLR. Oh well. ............................. There's nothing like the sound of incoming rifle and mortar rounds to cure the blues. No matter how down you are, you take an active and immediate interest in life. Fiat justitia, et ruat cælum