Building and Deploying Composite Application Guidance-Utilizing Application

Jan 20, 2010 at 2:34 PM

I have run into an issue here at work where we have the following scenario:

* We'll be porting numerous (30+) applications to C#/WPF/CAG

* There will be relatively few "Common" (widely-used) dll's

We have been discussing deployment as well as architecture and we keep running into the same issue: if we keep the build system the same, where all the forms are built at the same time and deployed all at once, forms that link to different versions of the Common dll's will break. In addition, I would like to make a case for CAG.

My questions are:

* How do we go about creating a build system that will ensure that our forms (some of which may not be updated once initially deployed) share the same latest Common dll's? Does ensuring we do not change the API work in this case? Or will a different version of the dll break the build for those older forms?

* Is it possible to reuse View/ViewModel code with CAG Modules? Bootstrap instances? In theory I was thinking of creating View/ViewModel classes which you would simply provide a custom repository (that implements an interface). Does this work in practice?

Thank you for your help,

Alex

Jan 22, 2010 at 1:03 PM

Hi Alex,

I will try to answer both questions separately.

About common shared DLLs

If I understand correctly you want to have multiple applications use the same common assembly, and have them continue working even if the common assembly is modified. I tested this by creating a common service project and referencing it from two Prism Quickstarts. To get the new assembly to work without building, all you have to do is replace (in my case copy/paste) in the required path. Take into account that the application has to be restarted when the new assembly is deployed.

About reusing View/ViewModel code

One of the benefits of having modular, decoupled applications, like those created following the guidelines of the Composite Application Guidance, is reusability.

If your goal is to create base implementations of Views/View Models to be  shared across the application, you should place them in an infrastructure project and reference to it from each of your modules.

If you want to have a single place (perhaps one or multiple assemblies) which would hold the different views of various applications, you should try to avoid having views from different modules in the same assembly, as this would reduce the decoupling between different modules. A better and more decoupled approach could be reusing modules between the applications (if possible). As each module is decoupled from other modules, there is no concern about using it in multiple applications and get the functionality you require.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman