GAC, Add Reference, solutions, and stds....
I am really not sure WHERE to post this question so I'm starting here -- since
our project is all C#.
We have joined the many that discovered the coding shortcut made in the IDE
where the Add Reference does not enumerate the GAC. I have yet to get the
registry key built in a way that the IDE recognizes I have made an entry
to add to the Add Reference list either. But that aside, with the team doing
various portions of the code, we have found each coder uses different ways
to do Add Reference.
You can compile the DLL and in the main project create reference to the DLL
by browsing. Works great for this one solution -- but move that solution
to a desktop that does not have the DLL compiled and you get broken code.
You can create reference by pointing to the project as well. We have one
solution that has about seven projects in it right now and references are
made to each DLL project. This is portable as long as you place the solution
in VSS along with all of the projects. Without the original solution, though,
the project becomes sensitive to the order you rebuild the solution. So
all of the dependant projects must be added then the main project added.
This is not good for support in the long run.
So now that leads to my query as to what others have done as a standard to
address this! What should be the standard for creating reference to a company
DLL? What should be the standard for DLL's that are for just this project
vs. ones that are reusable for many projects? One thought I had was to do
Each DLL is a stand-alone solution. Each solution is unit tested and then
compiled...with the DLL installed in a standard directory (GAC Projects for
example). I would like to get the GAC registry key figured out, because
then we can create a new key and export the registry keys to that directory.
This way I can transport the DLL library, with registration, and store it
on a network share which everyone can then run. This way if they need to
create reference to one of these they are no longer dependant on order, or
whether or not they compiled the DLL, or such. It will just be in the Add
I am also interested in what others have done for naming standards. We have
two separate DLL's (and probably more to follow) that create the System.Mycompany
namespace. Currently these are named only by the technology which matches
the namespace technology. eg. System.Mycompany.prgParseToXSL will be in
the DLL named prgParseToXSL. I thought that to be easier for coders than
naming the DLL to match the namespace name.
I am open to any opinions and directions other have to offer!