This post relates to the situation where some .Net applications have been converted to v2.0 but not all of them, so there is a mixture of v1.1 and v2.0 apps on the same server. There are some really good articles and blog posts on this subject already that have been immensely helpful, see here. But nothing beats having to tackle these problems for yourself!
So, I’m working for a client at the moment that has a mixture of classic ASP, COM+, Windows services, console apps an ASP.Net web sites and services, most of which are written in .Net v1.1, VB 6 and C++. We have written a new application in v2.0 of .Net and what to test out the effects of applying the .Net 2.0 framework to the server.
The key area of investigation is around evaluating what will happen when v2.0 of the framework is placed on these servers. If the answer is “nothing, all should be fine” then read on!
This mode of operation is side-by-side frameworks and avoids DLL hell to a large degree. What will be confusing to most people is the scenarios under which the latest version of the CLR is loaded despite some .Net apps being compiled under v1.1 of the CLR.
There seems to be a number of factors that affect the version of the CLR loaded into the appropriate process:-
- The version the app was compiled against that is held in the manifest
- For web-apps, the version on the ASP.NET tab
- The available versions on the target machine, e.g v1.1 app installed on machine with v2.0 only
- Any overrides specified in the config file (supportedruntime and requiredruntime elements)
- The nature of the client calling the .Net application (managed or unmanaged code).
Unmanaged Client
We have found that when an unmanaged client calls a .Net v1.1 application (that doesn’t have any .Net configuration file in the client folder area), the c:\windows\system32 directory is probed and the latest version of mscoree.dll is loaded. This is not suprising when you learn that v2.0 of the framework updates the mscoree.dll in this directory when it is installed onto the server.
Due to breaking changes between v1.1 and v2.0 of .Net here I would recommend that older versions of .Net apps run on the version of the framework that they were written for until such time that they can be upgraded and tested thoroughly. To this end, a simple fix to the above problem is to install a config file of the form:-
<unmanaged_application_name>.exe.config (e.g. testapp.exe.config)
into the folder where the client application is running from, that contains the following entries:-
<?xml version =”1.0″?>
<configuration>
<startup>
<supportedRuntime version=”v1.1.4322″/>
<requiredRuntime version=”v1.1.4322″/>
</startup>
</configuration>
Classic ASP pages calling .Net DLL’s directly from the page
So, the latest version of the framework loading into the IIS worker process relates to a .Net object or .Net DLL being referenced directly from a classic ASP page which uses COM interop (but not COM+). This will cause the IIS process to load the latest version of the .Net CLR and the .Net referenced DLL will run inside the IIS worker process with this version, which may cause problems depending on exactly what the .Net object/DLL does. If it uses parts of the CLR code where a breaking change has occurred between 1.1 and 2.0 there will be a problem.
If for instance the classic ASP page were referencing a .net DLL, by GACing the DLL and placing inside COM+ and running the DLL as a separate “server” process ensures that it will run inside the surrogate DLLHOST.exe having its own IDENTITY and process. Then the correct version of the framework CLR will be loaded into the surrogate process based on available versions and the requirements of the DLL within its manifest, e.g. if compiled as v1.1 with available CLR versions of v1.1 and v2.0, the process would have the v1.1 CLR loaded into the COM+ process.
If the classic ASP page is referencing a series of .Net objects directly from the page then Scott gives a solid solution here.
We used NTFileMon.exe from SYSINTERNALS (now managed by Microsoft) to establish the probing and eventual CLR version being loaded and used.
Code Access Security
It is worth being mindful of the fact that if you find yourself in the above mentioned position with the latest version of the CLR loading against your wishes, you will also then be forcd onto the latest version of Code Access Security (CAS). If you decide to keep the latest version of the CLR loading, ensure that your v1.1 CAS settings are also reflected in CAS v2.0.
For a thorough discussion of all of the above topics see here
Filed under: .Net, COM+, Coding Tips
