Removing Dependency Between Applications

Question

Dear Experts,
I need your valuable inputs on the architecture which we had in our organization but now want to change it due to considerable down time requirements.
I have a application A which stores all the common artifacts like schemas, maps and callable orchestrations.
I have 20 to 30 odd applications referring to the application A's artifacts. There is a dll dependency between the application and the common application A. so whenever I get a CR for an application A which involves change in the artifacts like schemas,
maps and orchestration, then according to the deployment rules of Biztalk, I have to delete all the 20 to 30 odd applications and then deploy the application A, then redeploy the other dependent applications. Now this produces a considerable down time of 3
to 4 hours.
Now the organization wants to change the approach and minimize the down time while keeping the development rework (i.e avoid adding same tags in the schema across 20 to 30 applications rather than importing them from common application A). While trying to
think about the solution I was reading various blogs on the internet and many suggested to go for side by side versioning. But the Organization wants to avoid that unless and until there are long running orchestrations(which is not the case right now) .
Now I followed following approach on my testing machine to check if it is feasible to make changes to the common application A without deleting the dependant applications first. I have separated the approach on the Development and Deployment Lines.
Development Wise
1) make the necessary changes in the schemas. Add a post build comment to do the gacutil on the schema project
2) For the maps referring to the schema provide the location of the freshly GACed dll. Provide the post build comment to do a gacutil on the maps project.
3) Do the same for the orchestrations.
4) for the dependant applications add the references from the GAC folder only.
Deployment Wise
1) As the common application is already deployed(before the new CR deployment), stop the Host Instances processing the common application requests and the Host Instances processing dependant application requests.
2) Install the msi on the server(not import)
3) GAC the individual dlls using the gacutil command 
4) Restart the Host Instances
This approach seems to work just fine and the changes in the artifacts are clearly observable.
But honestly I have doubts regarding the authenticity and the credibility of this approach. I require you guidance on whether this is a good approach to follow or not or is there any alternative approach available which I can use to avoid the problem statement.
Regards,
Mandar Dharmadhikari

Answer 1

The bad news:  What you're describing will usually work fine, but is not a supported Deployment method for BizTalk apps.
What you describe in "Development Wise" is all fine, but really doesn't matter.  The .Net references rules and how Visual Studio managed referenced assemblies isn't changed by those steps.  Referencing from the GAC or the build folder
should produce the same results.
The deployment dependencies is one of the reasons I decided long ago to avoid whenever practical, which so far has been always, the notion of 'shared' artifacts between deployment units.  My philosophy is a a Visual Studio Solution should be deployable
on it's own, without un-Deploying or re-Deploying anything else.  The one consequence so far is not being able to use the automatic schema resolution of the XmlDisassembler.
Sneaking in new versions is ok for DEV, but not something I would rely on for Production deployments.