Assembly Deployment and Version Management
-
I would like to gather opinions on the best way to manage the deployment and versioning of an API assembly. Our company has a primary web application (generic) with extensive backend databases. We also produce numerous smaller, customized web applications(client specific) that integrate in some way with the backend of the primary web application. (we host all apps ourselves) To ease the integration and speed up development of new custom web apps, we are creating an API assembly that will serve as a business logic/backend DAL of sorts to provide the custom apps with access to the primary application. My question is this: What is the best way to deploy this API assembly? GAC? local DLL in each custom web app /bin folder? This primary web app is still under developoment, so the API will need to change over time to accommodate these changes, as would the stored procs that support the API. If we use the GAC... a new version of the API would mean regression testing potentially 100's of custom web apps that rely upon it... not to mention any down time during the update (DLL and associated stored procs for several DB's) If we don't use the GAC... we've got multiple versions of the API dll scattered all over the place and different versions of stored procs within different databases (each client gets their own database). This method would allow us to deploy newer versions of the API only to custom apps that require it, leaving legacy apps alone. Any thoughts or opinions would be most welcome. Thanks.
-
I would like to gather opinions on the best way to manage the deployment and versioning of an API assembly. Our company has a primary web application (generic) with extensive backend databases. We also produce numerous smaller, customized web applications(client specific) that integrate in some way with the backend of the primary web application. (we host all apps ourselves) To ease the integration and speed up development of new custom web apps, we are creating an API assembly that will serve as a business logic/backend DAL of sorts to provide the custom apps with access to the primary application. My question is this: What is the best way to deploy this API assembly? GAC? local DLL in each custom web app /bin folder? This primary web app is still under developoment, so the API will need to change over time to accommodate these changes, as would the stored procs that support the API. If we use the GAC... a new version of the API would mean regression testing potentially 100's of custom web apps that rely upon it... not to mention any down time during the update (DLL and associated stored procs for several DB's) If we don't use the GAC... we've got multiple versions of the API dll scattered all over the place and different versions of stored procs within different databases (each client gets their own database). This method would allow us to deploy newer versions of the API only to custom apps that require it, leaving legacy apps alone. Any thoughts or opinions would be most welcome. Thanks.
Upon re-reading my post, I fear I might have rambled too much. Main question is this. Shared DLL assembly that will be used by 100's of web apps. What is the best way to deploy this shared assembly, considering the shared assembly version is not fixed... it may need to be updated once per month. GAC? this would mean regression testing the dependent apps(100's) for each new version. /bin folder? this would mean multiple versions of the shared assembly in use at any 1 time. What deployment method is best? thanks.