I can hardly believe I'm the first one to report this, but having gone
through the newsgroup, it appears that way.
I would like to open a solution in the VS.NET IDE that consists of
multiple DLLs and a test application (an .EXE). The .EXE is my startup
application. All the DLLs are shared components. This means that they
contain a key and are stored in the GAC.
When I go to run the test application in the IDE, it will not execute
because it complains that it cannot find the DLL or one of its
dependencies. Here are several pieces of information you need to be
aware of before going any further...
* I use version 1.1 of the .NET Framework (and VS.NET 2003)
* Many of the DLLs reference the other DLLs in the project and vice
versa. In essence, you have circular references. A class in DLL 'A'
uses a class in DLL 'B' and vice versa. This works, since it is
expected to.
* All DLLs are built in debug mode. No 'Release' versions even exist.
* No reference in any DLL has its "Copy Local" set to true. In other
words, a referenced DLL is never copied.
* All DLLs appear in the "Add References" dialog box under the ".NET"
tab. I set up a folder for each DLL in the registry to make this
happen. The folders appear under
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramewor k\AssemblyFolders
* The references that I use in the projects loaded in the IDE come
from the .NET tab in the "Add References" dialog box.
* I have verified that the GAC does indeed contain all DLLs and only
single versions of those DLLs.
* Every DLL is built to the \bin\Debug directory and each contains the
..pdb file (used by the IDE for debugging).
With everything setup this way, you would think that logically there
couldn't be a problem. When the IDE runs the main application, it will
notice that a DLL is in the GAC and that the Copy Local is set to
false, so the one in the GAC will be used.
Microsoft has written an article that states that you cannot reference
a DLL in the GAC, which is utterly wrong. I can reference it. They
state that you should copy the DLLs to a common directory and
reference them there. I did do this as well but it didn't help. I even
copied all the .pdb files to the common directory and that didn't help
either. I even set the reference paths in all DLLs to contain the
paths to all other DLLs. It didn't matter whether this path was the
common directory or the bin\Debug directory. It never helped.
What I ultimately discovered is that the only way to make it work is
to set the Copy Local to true. This of course had very serious side
effects. Now the DLLs poliferate all over the place. The same DLL will
appear in multiple directories. While working in the IDE and you
update one DLL, that update will NOT appear automatically in the
directories of other DLLs referencing it. You need to manually update
EVERY DLL use this newer version otherwise the debugging will not
execute. You can press the F5 button on all references in the IDE to
update the version and the newer DLL will get copied to those
directories but you still need to rebuild those other DLLs. Worse yet,
some DLLs may not be loaded in the IDE but are still referenced by
DLLs loaded in the IDE. You will need to update those as well.
This becomes a nightmare. The whole purpose of using a shared DLL is
to avoid duplicates. One version should exist and one only. If
Microsoft is making me copy them to some common directory, I can live
with that, if it would work while debugging in the IDE.
What really ticks me off is that having set the paths to all
references, you would expect the IDE to find the other DLLs and their
dependencies. What in the world am I setting that for if it doesn't
use it? There is no reason, having done all I did, that the IDE should
not find every one of the DLLs and the debug files.
Has anyone got a clue what can be done?
Thanks,
Johann Blake
www.closerworlds.com
Mobile Solutions using GPS
