The Old Joel on Software Forum: Part 3 (of 5)

.net mismatched runtimes

can someone describe how to know what version of the platform some code is running on? a few machines here have both 1.1 and 1.0 frameworks installed, but one program (an nunit test suite) fails on some machines, apparently due to a version mismatch. From what I can find on the net, the framework is trying to load system.xml from the wrong version and thus fails with a StrongNameIdentityPermission error.

Makes you wish for a static linked runtime... but also makes you wonder abut the security implications of such a thing, both good and bad.

mb
Wednesday, January 28, 2004

Do you mean at runtime, or do you mean how to manually determine the Framework?

You can look in the C:\WINDOWS\Microsoft.NET\Framework and it will have a sub-directory for each version of the Framework.

As for runtime, I don't know but I would guess this is doable.

Mark Hoffman
Wednesday, January 28, 2004

Here we go:

http://groups.google.com.au/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&safe=off&threadm=%23gAN2zuIDHA.3272%40tk2msftngp13.phx.gbl&rnum=7&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26safe%3Doff%26q%3Ddetermine%2Bclr%2Bversion%2Bgroup%253Amicrosoft.public.dotnet.*%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dmicrosoft.public.dotnet.*

Matthew Lock
Thursday, January 29, 2004

ok, so if I wrote the program I could call the System.Envrionment.Version property, and maybe (on 1.1) call System.Reflection.Assembly.GetExecutingAssembly.ImageRuntimeVersion

But of course that's not always the case. Something broke and it seems to be a version mismatch but I didn't actually write the code. Well at least part of it is under our control, we'll check out those properties tomorrow.

Maybe it's time to write a manifest to control what's happening.

mb
Thursday, January 29, 2004

How about attaching an unmanaged debugger to the process and seeing what DLLs are loaded?

You can even do this without installing any software:
ntsd -p <processid>
from the command line will produce a window with a bunch of ModLoad: lines.

Running against SharpReader on my machine I see:

ModLoad: 791b0000 79412000 C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorw
ks.dll
ModLoad: 7c340000 7c396000 C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\MSVCR7
1.dll
ModLoad: 79040000 79085000 C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion
.dll
ModLoad: 77380000 77b5d000 C:\WINDOWS\system32\SHELL32.dll

Which I take to mean it is running v1.1.

Hopefully you won't see references to both Framework\v1.1.x and FrameWork\v1.0.x in the same process. I doubt this is possible ... but on the other hand wouldn't be surprised!

Oh - and type q in the window to quit the application (this will kill it though)

Rob Walker
Thursday, January 29, 2004

alright, the problem has been 'fixed' but I have no idea what is going on.

According to http://msdn.microsoft.com/library/en-us/dnnetdep/html/sidexsidenet.asp , the CLR will use the version of the framework the program was compiled with, or failing that, a newer version.

But on both my machines I have both 1.0 and 1.1 frameworks. The program is the same. But when I used handle (from sysinternals), on one machine some of the open files are 1.1, and on the other, 1.0.

When I added the 'startup' block to the app.config file, everything ran again. Yeah...

<startup>
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
</startup>

mb
Thursday, January 29, 2004