467,907 Members | 1,422 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,907 developers. It's quick & easy.

Assembly referencing problem with creating third party plug-in

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
Nov 15 '05 #1
  • viewed: 1342
Share:
2 Replies


"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:O0**************@TK2MSFTNGP10.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.CurrentDomain.BaseDirect ory);

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
Nov 15 '05 #2
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
"Joe Mayo" <jm***@ddiieessppaammeerrssddiiee.com> wrote in message
news:Ow**************@TK2MSFTNGP10.phx.gbl...


"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.net> wrote in message
news:O0**************@TK2MSFTNGP10.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.CurrentDomain.BaseDirect ory);

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

Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Tony Jones | last post: by
6 posts views Thread by Wolfgang Keller | last post: by
2 posts views Thread by EAI | last post: by
reply views Thread by Mikael Engdahl | last post: by
11 posts views Thread by Michael Maes | last post: by
reply views Thread by Scott F K Hooper | last post: by
8 posts views Thread by Dale | last post: by
2 posts views Thread by Shilpa | last post: by
1 post views Thread by Curious | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.