2

Where I'm at we have a large number of programs that can run that all use features from a set of assemblies located on a network share: things like writing to a common systems log, DB connection strings, some common business objects and functions, etc.

We like this setup, because it makes it easy to deploy bug fixes and new features: just update the assemblies on the shared drive and every app the uses them is up to date. Need to break binary compatibility? It's not done lightly but still not a big deal: just add a new folder with the new version number. Subversion knows where each version is so bug fixes can still be deployed to code duplicated in each version. There would likely also be some discussion first to make sure it's really necessary and so we can batch several changes into one new set, but the need to do this at all has been pretty rare to this point.

To support this, we have a few custom project templates that automatically include references for the common libraries, and again: we really like this setup.

Now finally for the meat of the question — much of what we do is supporting a large number of small legacy classic ASP pages. These, along with new development, are slowly moving to .Net as well. We really want to be able to use the same support framework for these web apps that our other applications use. Conventional wisdom says that an ASP.Net app cannot reference assemblies outside of the GAC or it's own little virtual directory. Thus to use our common code in our ASP.Net pages the best we could do is to install it to the GAC on the web server and every developer machine, and make sure every update to this code is propagated to those locations as well. We find that distasteful.

Given that we can give the ASPNet account the required permissions to read from the network share where the common code lives, and that we'll be building some custom project templates for these apps anyway (so would could automatically include some settings in the web.config or subclass the normal asp.net page class as our starting point, for example) does anyone know of any unconventional wisdom that says we might be able to reference these assemblies from their current location after all?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794

2 Answers2

2

Joel, would it not be possible to leverage the <codebase> element of the configuration file of your applications? AFAIK, it handles UNC shares, and if you're already putting new assembly versions in named folders, it seems like the appropriate config files could be updated with a new <codebase> element when a new version is rolled out, maybe through the use of a subversion hook script.

One hitch would be if you made an update without changing the version number, since the machines would have already downloaded a copy and would likely be unaware of the change.

womp
  • 115,835
  • 26
  • 236
  • 269
0

As far as I know, the only way (without code) to share assemblies in ASP.NET is the GAC (or maintain a copy local to each site and make sure each is up to date) like you said.

It might be more trobule than it's worth, but is there any chance of writing a single assembly that COULD be loaded into the GAC on your web servers?

My thinking is that you could write a single assembly in the GAC that would, through conventional references or reflection, marshall your request for objects from the other shared assemblies on your shared drive.

That way you would have minimal maintenance headaches for the assemblies in the shared folder, and really only have to worry about keep the single assembly in the GAC up to date.

...writing the code for that assembly could always wind up being more trouble than it's worth though.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536