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]

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.CurrentDomain.BaseDirectory);

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

 

[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.CurrentDomain.SetDynamicBase()

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

Thanks,
Jon