Referencing DLLs from code

Ron Howerton · October 19th, 2012, 12:52 PM

I have created a user control which I have compiled to DLL. The DLL is referenced by a score of different web applications. It is referenced by browsing to the DLL in a shared folder on the IIS server from the IDE for each project and then consumed by various pages.

I have since noticed that published folders on the IIS server each contain a copy of this DLL. This suggests that all of these programs will need to be republished every time this DLL changes to ensure the new DLL is copied to each application's production folder. And indeed, the projects in question appear to force me to drop and re-reference the DLL when it changes.

This seems counterintuitive - shouldn't all applications reference the same copy of the DLL in one shared folder via registration in the GAC? Isn't the purpose of using a DLL to avoid creating duplicate files that previously caused confusion when they did not match? Have I somehow incorrectly established the reference in some way that requires making a copy of the DLL in the applciaiton BIN ofolder?

Imar · October 19th, 2012, 03:01 PM

Quote:

shouldn't all applications reference the same copy of the DLL

It depends. By enabling applications yto have their own private copy you minimize DLL hell where an update of the assembly could potentially break many applications that use it.

Quote:

in one shared folder via registration in the GAC

Yes, it you want to share the same copy, the GAC is your answer. Register the assembly in the GAC and then make sure "Copy Local" is set to false for the reference oiin your VS project.

Cheers,

Imar

Ron Howerton · October 19th, 2012, 03:32 PM

Ah - that's why it felt like the opposite side of DLL hell! I do not recall enabling this for any project so it must be the default setting.

Thanks for the clue, as always, Imar!

Ron Howerton · October 22nd, 2012, 04:27 PM

Still struggling with this. No matter what I do, it will not allow me to add the new control to the existing project that worked before making this change. It keeps telling me it's not a .NET module. And I just compiled the control using .NET!

What could cause VS to think it is not a .NET module, particularly when I am able to load the old DLL from its location?

Imar · October 24th, 2012, 06:47 PM

What type of DLL is it? A .NET Class Library? How do you add it? And have you added it to the GAC?

Imar

Ron Howerton · October 25th, 2012, 08:40 AM

Thanks for the response, Imar!

The DLL is compiled from a .NET Web Control Library project containing a single public class consisting of a couple of labels and a few properties that can be set on the interface or at run time. I compiled it and copied the DLL to a shared folder on our IIS server. I then added it to the project via the Add References dialog box browse tab. Using Choose Items from the toolbox context menu I then browsed to the shared location and added the control to the toolbox. Dragging it from the toolbox to the page definition registered it for the page. It worked well enough this way, but made copies of the DLL in the BIN folder of every application referencing it this way.

This time, after copying the DLL to the shared location, I registered it on the server manually using GACUtil /if option from the cmd prompt. I also verified registration using the /l parm and the registered component appears only once. I again referenced the DLL with the consuming application from Add References. But when I try to Choose Items from the toobox, it tells me it's not a .NET module?

When

Imar · October 28th, 2012, 03:11 PM

To be honest, I have no idea..... ;-)

Is the DLL you're adding to VS on your local machine? Did you add it to the GAC there as well?

Imar