Assembly referencing problem with creating third party plug-in

[Jon Davis]

I have a full-blown application that consists of several (fifteen or so)
assembly DLLs, each being a separate VS.NET project that outputs to the main
DLL's bin directory. They are all strongly named. I have registered the main
DLL, which references the other DLLs, to the GAC cache.

I have built a plug-in for a third party application with which I load the
GAC cached assembly. But it doesn't find the dependencies.

I just spent hours getting everything strong-named and getting the main DLL
into the cache, and it seems that I haven't gotten anywhere, as the
referenced DLLs still can't be found. Seems that the GAC cache really does
cache and doesn't just provide a reference point to the DLL and its runtime
directory.

How do I resolve this problem so that I can get the plug-in for the third
party app working?? I REALLY DON'T want to spawn a new process and use
Remoting!!!

Thanks for any help.

Jon

[Joe Mayo]

"Jon Davis" <jo*@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:O0******** ******@TK2MSFTN GP10.phx.gbl...

I have a full-blown application that consists of several (fifteen or so)
assembly DLLs, each being a separate VS.NET project that outputs to the main DLL's bin directory. They are all strongly named. I have registered the main DLL, which references the other DLLs, to the GAC cache.

I have built a plug-in for a third party application with which I load the
GAC cached assembly. But it doesn't find the dependencies.

I just spent hours getting everything strong-named and getting the main DLL into the cache, and it seems that I haven't gotten anywhere, as the
referenced DLLs still can't be found. Seems that the GAC cache really does
cache and doesn't just provide a reference point to the DLL and its runtime directory.

Hi Jon,

The CLR looks for assemblies in the GAC first and then in the Application
Base directory and then in subdirectories named after the dll it is looking
for. It sounds like, the referenced DLLs are not in the Application Base
directory. You can use the following command to see what the CLR thinks
your base directory is:

MessageBox.Show (AppDomain.Curr entDomain.BaseD irectory);

The Base Directory should also show up in your Fusion log. You can see this
if your exception bubbled up to the top and crashed your program. However,
if you had good exception handling in place, you may not see it. In this
case, launch fuslogvw.exe, check the Log Failures box, run your program and
let it generate the exception, and press the Refresh button on the Fusion
Log console window. When you press the View Log button, the fusion log will
pop up in IE. At the bottom of this log, you'll see four entries that say
"LOG: Attempting download of new URL file:///...". This is where the CLR is
looking, but can't find your DLLs.

If it is guaranteed that this will be the only place that those DLLs will
reside, even after deployment, then you can copy your DLLs into that
directory. Otherwise, add them all to the GAC.

Joe
--
http://www.csharp-station.com

[Jon Davis]

I see. Well I can't add all the DLLs to the GAC because a lot of them are
COM wrappers and that would just be GAC [gack!] bloat.

What about ..

AppDomain.Curre ntDomain.SetDyn amicBase()

.. might this be of any use for me? (Looking into this further ..)

Thanks,
Jon
"Joe Mayo" <jm***@ddiieess ppaammeerrssddi iee.com> wrote in message
news:Ow******** ******@TK2MSFTN GP10.phx.gbl...

"Jon Davis" <jo*@REMOVE.ME. PLEASE.jondavis .net> wrote in message
news:O0******** ******@TK2MSFTN GP10.phx.gbl...

I have a full-blown application that consists of several (fifteen or so)
assembly DLLs, each being a separate VS.NET project that outputs to the main

DLL's bin directory. They are all strongly named. I have registered the

main

DLL, which references the other DLLs, to the GAC cache.

I have built a plug-in for a third party application with which I load the GAC cached assembly. But it doesn't find the dependencies.

I just spent hours getting everything strong-named and getting the main

DLL

into the cache, and it seems that I haven't gotten anywhere, as the
referenced DLLs still can't be found. Seems that the GAC cache really does cache and doesn't just provide a reference point to the DLL and its

runtime

directory.

Hi Jon,

The CLR looks for assemblies in the GAC first and then in the Application
Base directory and then in subdirectories named after the dll it is

looking for. It sounds like, the referenced DLLs are not in the Application Base
directory. You can use the following command to see what the CLR thinks
your base directory is:

MessageBox.Show (AppDomain.Curr entDomain.BaseD irectory);

The Base Directory should also show up in your Fusion log. You can see this if your exception bubbled up to the top and crashed your program. However, if you had good exception handling in place, you may not see it. In this
case, launch fuslogvw.exe, check the Log Failures box, run your program and let it generate the exception, and press the Refresh button on the Fusion
Log console window. When you press the View Log button, the fusion log will pop up in IE. At the bottom of this log, you'll see four entries that say
"LOG: Attempting download of new URL file:///...". This is where the CLR is looking, but can't find your DLLs.

If it is guaranteed that this will be the only place that those DLLs will
reside, even after deployment, then you can copy your DLLs into that
directory. Otherwise, add them all to the GAC.

Joe
--
http://www.csharp-station.com