You need to realize that any process can only load one version of the CLR. Once the CLR has been loaded into a process, the only way to unload it is to exit the process; the only way to load a different version is to start another process. (Source: Pratschner's "Customizing the Microsoft .NET Framework Common Language Runtime.") Bryan's "if you are self-hosting the CLR I suppose you could dynamically change the CLR" is in fact not correct.
If DLLHOST.exe loads the wrong version (from your perspective) of the CLR before your COM+ application gets started, you no longer have any control over the CLR version used. Furthermore, even if you "win" and get DLLHOST.exe to load the CLR you want, that automatically controls the CLR that any other COM+ apps use, if they're under the control of the same instance of DLLHOST.exe. The following would be a mighty kludge, but perhaps it would work. Make two copies of DLLHOST.exe named DLLHOST11.exe and DLLHOST20.exe; make DLLHOST11.exe.config that specifies the 1.1 CLR, and DLLHOST20.exe.config that specifies the 2.0 CLR. Then find the registry references to DLLHOST.exe for your COM+ apps and change them to refer to the version you want used. (Easier: make only DLLHOST11.exe [or DLLHOST20.exe], and only change the references to COM+ apps that require 1.1 [or 2.0], rather than requiring that each that has a specific CLR version requirement have its registry entry changed.) If your COM+ apps are going to talk to each other and they use different CLR versions, that might screw things up royally because there'll be more than one DLLHOST process. But as DLLHOST.exe can't break the "only one version of the CLR per process" rule, I don't see that you've got much choice but to try the kludge or make every COM+ app suffer with the same CLR version. A less kludgey technique would be to host the COM+ apps that need 1.1 on a machine that only has CLR 1.1, and host others on a machine that has only 2.0. However, then your apps using different CLR versions would need to do cross-machine communication rather than cross-process communication. Good luck!!! At 05:43 AM 7/20/2006, Charles Gamble wrote >Hi, > >I have tried using the application.config and application.manifest files and >setting the Root Directory of the COM+ application, but this is not >affecting which version of the .NET framework is being loaded. >Note, I know the .config and .manifest files are being accessed as I ran >SysInternals.com FileMon utility and it shows they are used. However, it >seems that the <startup> tag in the .config file is not having any affect. >It works fine if I put it into the DLLHOST.exe.config, but this will then be >used for all COM+ apps. > >Any ideas why this isn't working ? >By they way, what is the manifest file used for ? > >Regards, > Charles. > >-----Original Message----- >From: Discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] On Behalf Of Matthew Wills >Sent: 19 July 2006 00:18 >To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM >Subject: Re: [ADVANCED-DOTNET] Loading specific .NET framework > >Charles, > >http://dotnet.org.za/armand/archive/2004/05/30/1917.aspx > >Have a play with the above technique and see if it works. I am not sure it >will, but its worth a try. > >Seeya >Matthew Wills @ MLC >Senior Analyst Programmer > > > >|---------+----------------------------------> >| | Charles Gamble | >| | <[EMAIL PROTECTED]| >| | RITY.CO.UK> | >| | | >|---------+----------------------------------> > >>--------------------------------------------------------------------------- >-----------------------------------| > | >| > | To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM >| > | cc: >| > | Subject: Re: [ADVANCED-DOTNET] Loading specific .NET framework >| > >>--------------------------------------------------------------------------- >-----------------------------------| > > > > >Thanks for the help so far on this. >Are there any web links explaining how the version of the framework to use >is determined when a process first loads a .NET DLL? >The process I am talking about specifically is DLLHOST.EXE, as we are >hosting .NET DLLs in COM+. >We would like to control the version of the framework to use in a mixed >environment (.NET 1.1 and 2.0 installed), however if we do this via >DLLHOST.exe.config file this will affect all COM+ applications on the >machine. > >Any other way of doing this in code or declaratively ? > >Thanks, > Charles. > > >-----Original Message----- >From: Discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] On Behalf Of Bryan Porter >Sent: 18 July 2006 17:10 >To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM >Subject: Re: [ADVANCED-DOTNET] Loading specific .NET framework > >Salutations Charles, > >As I recall, a process can only have one instance of the CLR loaded >at any given time. If you are self-hosting the CLR (i.e. an unmanaged >C++ application using the CLR COM objects) I suppose you could >dynamically change the CLR (with the result of unloading any >AppDomains currently loaded when you switch); however, it is trivial >to specify which framework is required in the App.config file; see >MSDN for more details on this. > >Regards, >Bryan Porter > > >On Jul 18, 2006, at 9:17 AM, Charles Gamble wrote: > >> Is there any other way to load a different version of the .NET >> framework in >> a process other than using .NET configuration files ? Can the >> version loaded >> be changed while a process is running ? >> >> How exactly is the version of the framework to use determined ? >> >> >> >> Any help is appreciated, >> >> Charles. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
