views:

48

answers:

3

A user reported to us that some strange behaviour in our application can be resolved after installing .NET 4:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>

I wasn't aware that if you didn't specify an assembly it might be loaded in a higher, but compatible version.

Is it possible to identify which framework an executable is executing with? at run-time? or through some external process? I wish to confirm that this is the case, and the users experience has not be the result of some other issue.


Process Explorer says EVEMon is running under the 2.0, I am inclined to suspect the issue is was environmental:

Process Explorer

+4  A: 

From within your assembly's running code, you can use the System.Environment.Version static property to determine the CLR version under which it is executing.

If you don't want to change the assembly code, you could use Process Explorer to see the DLLs loaded in the process at runtime. The CLR version can be identified from the version of mscoree.dll.

Nicole Calinoiu
Process Explorer says 2.0, strange.
Richard Slater
+1  A: 

Doesn't make sense, a program that was targeted for CLR version 2.0.50727 won't automatically run with .NET 4.0. An explicit .config file entry is required. Given your client's prowess with .config files, this might be something that she in fact did, then found out there was trouble.

Hans Passant
However a 2/3/3.5 targeted assembly could be loaded into a 4.0 process.
Richard
+1  A: 

As Nicole said Process Explorer is definitely the easiest way. You can also get this information from a Full Memory Dump using WindDBG.

Also note that with 4.0 you get side by side CLR hosting. Prior to 4.0 if you didn't own the process you had no way of knowing what CLR was loaded. This can be a reason why you experinced the behavior you described.

Conrad Frix