How to Get Compiler Version at Run Time?

[richard.martino]

Now that Visual Studio 2008 is out (and another department compiles
our production code), we want to know (at run time, in the manifest,
or by examining the executables) which compiler compiled our source
code?

How can we tell, after the fact, which compiler compiled our source
code?

Thanks.

 

[Larry Smith]

Now that Visual Studio 2008 is out (and another department compiles

our production code), we want to know (at run time, in the manifest,
or by examining the executables) which compiler compiled our source
code?

How can we tell, after the fact, which compiler compiled our source
code?

Honestly, I don't know if a native way exists to do this but I'd be
surprised if there was (but you never know). You can always add your own
custom assembly attribute however and read this at runtime (via
"Assembly.GetCustomAttributes()"). I'm referring to a custom attribute you
would create and add to each project's "AssemblyInfo.cs" file (say,
"SourceCompilerAttribute"). In your case you may want to add this to a
central file instead of each project's "AssemblyInfo.cs" file. All projects
in your solution can then "link" to it. This file is typically called
"SolutionInfo.cs" which you can Google for. Here are a couple links I
quickly found which seem to discuss the issue (though I didn't read them in
detail - I originally discovered this technique in the book "Programming
..NET Components" by Juval Lowy - he's recognized by MSFT as a leading .NET
expert):

http://bloggingabout.net/blogs/jsch...C00_-or-simplify-versioning-of-solutions.aspx
http://ilmatte.wordpress.com/2008/02/10/solutioninfo-and-partitioned-single-solution/

 

[Ben Voigt [C++ MVP]]

Honestly, I don't know if a native way exists to do this but I'd be
surprised if there was (but you never know). You can always add your

dumpbin should tell you the linker version, and hence which version of
Visual Studio was used.

 

[Larry Smith]

dumpbin should tell you the linker version, and hence which version of

Visual Studio was used.

There may be other utilities as well but if I read the op's intentions
correctly, it's likely unsuitable in this context (not portable, difficult
to apply in code, potentially unreliable, unavailable on a typical client
machine, etc.). Maybe he should clarify the usage environment.

 

[Leo Violette]

Are they different versions of the compiler or the same version?

If different, you can run Depends to see what C Runtime libarary or MFC or
ATL library its dependent on.

OR

You could do it programatically by adding code to your about box to display
things like:
_MSC_VER
_MFC_VER
_ATL_VER
etc.
http://msdn.microsoft.com/en-us/library/b0084kay.aspx

 

[Leo Violette]

Crap! Sorry, I forgot this is a C# newsgroup. Disregard my last post.

 

[Pavel Minaev]

Now that Visual Studio 2008 is out (and another department compiles
our production code), we want to know (at run time, in the manifest,
or by examining the executables) which compiler compiled our source
code?

How can we tell, after the fact, which compiler compiled our source
code?

Frankly, you shouldn't care in the slightest. Here's why:

1) Compiler version has nothing to do with framework version. You can
use a C# 3.0 compiler to produce an assembly that happily works with
2.0.

2) C#-the-language is 100% backwards compatible by design. All new
features are introduced in such a way that any code compliant with an
earlier version of C# standard will keep working for a newer version
with exact same semantics.

 

[Ben Voigt [C++ MVP]]

Frankly, you shouldn't care in the slightest. Here's why:

Sorry, for as long as the list of compiler bugs is version-dependent, the
compiler version number will be an important piece of information in all bug
reports.