Combining Silverlight, Prism and CRM - take 1

Introduction​

During a visit to the eXtreme CRM conference in Berlin, I had the oppurtunity to attend a session named "Silverlight & MS Dynamics CRM development". This session had some interesting content regarding how to use composite frameworks (Prism) to build more modular and reusable Silverlight applications for the CRM platform.

The session was recorded and can be found on youtube:

http://www.youtube.com/user/4thmodule?feature=watch&cm_mid=1254131&cm_crmid=%7BE995B1EE-DA4C-E111-8D46-1CC1DEE89A74%7D&cm_medium=email

Take 1

Finally I now managed to do my own take 1 on combining Silverlight, Prism and CRM. The aim was to build two simple silverlight applications, both using the same module for CRM communication. To do that I ended up with the following components in VS:

1. AccountApplication project - silverlight xap

Test application which displays a list of all associated contacts for a specific account. Will be run on the account form.

2. ContactApplication project - silverlight xap

Test application which displays the name of the associated customer for a specific contact. Will be run on the contact form.

3. Common project - silverlight xap

Common module on which both the AccountApplication and ContactApplication has a dependency. In my example, the common module contains functionality for communication with CRM, but in principle it could contain anything.. fx. CRM styling of controls.

4. Shell project - silverlight xap

This is the typical Prism container, which is the actual webresource being placed on the account- and contact entity forms. The shell is then configured to run either the AccountApplication or the ContactApplication. This is done using xml configuration web resources.

5. Interface project - silverlight xap

This project only contains a single file, which is the interface for CRM communication. This is the only project referenced by projects 1,2,3 and 4. Prism offers other ways of commicating between modules, this interface-based approach is only one option.

6. Module catalog xml file for AccountApplication.

Contains the information that the AccountApplication should be loaded into the shell, and that the AccountApplication depends on Common.

7. Module catalog xml file for ContactApplication.

Contains the information that the ContactApplication should be loaded into the shell, and that the ContactApplication depends on Common.

The following diagram illustrates this structure:

When the shell creates its module catalog, it uses the information obtained from modulecatalog.xml. In case of the AccountApplication, this will load the accountapplication module and the common module since this is configured as a dependency. The AccountApplication then registers its view with a region defined inside the shell. This way the accountapplication is displayed.

Deployment in CRM

What I did to deploy the above to CRM was the following:

1. Upload all xap files (besides Interface) as webresources in CRM.

2. Upload the account and contact module catalogs as webresources.

3. Place the shell silverlight web resource on the account and contact forms respectively.

4. Pass the name of the correct module catalog to each of the two shell web resources.

Result

In this simple example, the common component is reused between the two applications without modification. In a more complex scenario, with multiple SL apps, each maybe with several views, more regions etc.. the advantage of using the composite pattern will be somewhat more clear.