xRM Consultant

Hi,

As you may (or many not) know i have been working on our largest CRM implementation which also happens to be out first large scale CRM 2011 implementation. As such, we have started working with solution files!

First of all, I would like to say that I really love the concept of solution files. Making changes for either support or development purposes on clients CRM systems in CRM 4 felt very clumsy and poorly controlled. The introduction of solutions dealt with this in a way that feels much more professional. However, the question arose, what is the best practice for using solutions?

The Problems

Surprisingly, i couldn't see many (if any) articles or details on this. So we started out by, on our development environment, creating a solution file using the client name and using the version number to control this. We added all the existing system components and made changes to these as we went along. However, the problem with this is that development felt a bit cumbersome. You couldn't use the native “Customise” tab on forms as this edited the default solution as well as the fact that all members of the team had to remember to stick to the solution only and not do this.

We also had major issues when applying the solution that came from the way our solution was interacting with another managed solution. We installed our main solution on one of the clients servers after which, we installed the brilliant eCampaign (great email marketing extension for Dynamics CRM 2011) on the one of the clients servers. The problems started when we subsequently made changes (by creating another solution file) on this server.

When we tried to export our solution file, we were quite rightly warned that components were missing. So, we added the components. We did this until it appeared that all the required components (including those used by the managed eCampaign solution) were included. When we tried to import the solution into our Dev environment it failed because, you guessed it, we couldn't import components of a managed solution! So, we went back, removed all components of the managed solution, re-exported ignoring the warnings about missing components. When we tried to import it into our Dev environment………it failed because of missing components!!! The only “solution” was to edit the XML solution file, something we were very uncomfortable with at this stage.

Now, i know what your thinking. Why on earth are you developing on a client server!! And, to be honest your right. It was necessary at the time but bad practice which brings us back to what should be our future practice. For those of you interested, the way we got around the above situation was to ask the vendor (eCampaign) to uninstall the managed solution, export our solution file (which now no longer required the missing components) and reinstall the managed solution after.

The Best Practice (Well…according to me anyway)

So the moral of the story (or what we have learned so far is…)

1. Create a Deployment for your Client on your development environment
2. Develop in the “Default Solution”.
3. When ready to deploy on your client server, you have 2 choices:
• Export The Default Solution – If this is exported as managed, then when imported it will show as “Default Solution” in the clients list of installed solutions. If it is exported as unmanaged, it will overwrite the existing default solution and as such, wont appear in the clients list of solutions.
• Create A New Solution & Add The Relevant Components – When exported either as managed or unmanaged, it will show in the solution list.
4. For small changes you also have 2 choices:
• Create  A Single Solution File With Relevant Components – Create a solution file with a relevant name (i.e. ClientName Updates 2011) and add the relevant components. Every time the client wants changes made, create a solution with the same name but different version number on your Dev environment and when importing as a managed solution, it will update the existing solution. You can of course always do this with your solution file created in step 3 with the same results.
• Create Multiple Solution Files For Each Change Batch – Create a solution with a unique name and install on your clients environment.
5. For major changes, i would go through step 3 again.
6. When working with other managed plugins, always uninstall them from your Dev environment before exporting your solution.

Of course, all of the above is only what i have learned so far and my opinion on best practice. It would be nice to see some more on this so that CRM developers can share methodology for the above, but for now, this is the approach i will take. As it changes (as i am sure it will) i’ll keep you up to date!

Thanks

J