aaronh64
5/10/2007 9:37:00 PM
I'm hoping to hear about some people's experience/suggestions building
and deploying .NET 2.0 applications that rely on shared components.
Specifically, I have a few levels of strongly named depencies:
[Windows Services] --> OE.DLL --> BL.DLL --> ML.DLL
[ASP.NET UI] --> BL.DLL --> ML.DLL
I am in an environment where I have created 6 windows services that
rely on OE. OE relies on BL, BL relies on ML. Both OE and BL change
frequently, and recompiling each windows service after OE changes or
BL changes is unacceptable. In addition, there is an ASP.NET UI that
references BL.
I'm looking for any efficient packaging/deployment ideas that you
might currently use or have seen used in a scenario like this. For
example, should I create a setup project for OE, and anytime OE or BL
changes, I just stop all of the services and run the OE setup,
updating the GAC, and restart the services? Should each Windows
Service have its own setup project, and reference another setup
project?? Should the BL and OE have their own setup projects???
Thanks for any ideas you may have.