If you use virtualization (e.g., Vserver, VMWare, etc.), those two machines
could in fact be just one, and the cross-machine communication would just
incur in protocol overhead and not in latency and transmission delays.
Just 2 cents.
LV.
----- Original Message -----
From: "J. Merrill" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 20, 2006 6:12 PM
Subject: Re: [ADVANCED-DOTNET] Loading specific .NET framework
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: [email protected]
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: [email protected]
|
| 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: [email protected]
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
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
