views:

43

answers:

1

I have a library that is meant to be used by many websites. The way I am doing it now is in the library's properties, I set the "Post-build event command line" to: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite\bin\$(TargetFileName)"

Every time I want a new website to use the shared library, I add a new line like this: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite2\bin\$(TargetFileName)"

Is there an easy or better way to do this besides using the GAC?

+2  A: 

In my opinion your problem here is a lack of control about how this library is produced and used by other projects. If I were you (which I'm not :) I'd set about developing the library through a unit test co-project where new functionality can be developed and tested independently. Once that functionality has been implemented and tested to be working within your unit test parameters manually copy the assembly into a "library" folder of the web project that the required the extension of the library in the first place (this folder holds all your compiled assemblies used by that project).

Even better would be to maintain a version system in which you tag the new version of the library so as to keep track of the exact source revision that it's using.

The reason I suggest what may seem like a cumbersome methodology of working is that your current practice makes your existing websites quite brittle as a change made in the library for one site may in fact break one of the other sites... and as the amount of sites you have increases you can't be forever retro testing new versions of the shared library against the existing sites.

It's also for these reasons that I don't recommend using the GAC either.

If he versions his assembly every time he makes a new build for it, putting it in a GAC shouldn't be an issue as long as his installer keeps previous versions intact in GAC.
VinayC
You are so right that I should not automatically copy the assemblies without a testing framework in between them. Thanks for the insight!! :)
TruMan1