Re: App.path - equivalent - in an interop DLL
From: Chris Gallucci (chris_at_gallucci.com)
Date: 05/18/04
- Next message: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Previous message: AlexS: "Re: problem with MouseEnter event on a Custom Control"
- In reply to: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Next in thread: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Reply: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 18 May 2004 10:58:07 -0500
Ellen,
I may be a little off on this explanation as far as the details (and I welcome any/all corrections) but the gist of what I'll say
should be accurate...
.NET assemblies by default do not rely on the Registry for calling applications to identify their location so that they can be
loaded in the calling program's process space. They look to the calling progam's executing location. (not sure, but they may also
look to your environmental variable PATH).
So if the dll isn't in the same location as the exe, there's no way for the exe to know where that dll resides so that it can be
loaded.
Enter the GAC. The GAC allows you to install .net assemblies in a common location so that essentially the assembly can be shared.
There's a lot more to the GAC as I've purposely over-simplified my description. (I'll leave it to others to provide any needed
detail). Making an assembly available for COM Interop requires registration in the GAC.
In a nutshell, the behaviour you're seeing is by design.
HTH,
ChrisG
- Next message: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Previous message: AlexS: "Re: problem with MouseEnter event on a Custom Control"
- In reply to: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Next in thread: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Reply: Ellen: "Re: App.path - equivalent - in an interop DLL"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
