One challenge you face as an xRM development team is management of the customizations. Even with the addition of Solutions in CRM 2011, maintaining customizations across multiple environments poses several challenges, such as:
- Maintaining a common schema – across multiple CRM instances, how do you ensure that all entities have the same schema?
- Stepping on teammates’ work – when one developer deploys their latest work, how do you ensure other’s work is not overwritten?
- Entity and attribute cleanup – as the schema for a project solidifies, how do you ensure old and unused elements are not unnecessarily deployed to production?
One approach in managing shared customizations is to mandate your team to work on a shared CRM instance. The shared instance serves as the master customizations copy from which deployments are cut and checked into source code control. This will ensure that all developers are working against the same copy of customizations, scripts, workflows and other solution components. This approach can quickly become unwieldy or costly. The shared instance my not have enough resources such as RAM or CPU that makes multiple concurrent developers almost impossible. Some tasks may involve work that impacts others, such as updating a shared entity or script library. Development and testing of work in progress often impedes the team if a developer is debugging or changing shared resources. Your team can take a hybrid approach: maintain the master copy of customizations while developers perform day to day work on own local instances. While the hybrid approach offers flexibility for developers while ensuring a master customizations copy, your team still faces the issue of syncing up the developer’s work to the master copy.
A Helpful Utility
One tool available to you when syncing your customizations is the CRM Solution Packager tool. This utility is a command line application included with the CRM SDK and will both extract and repackage a CRM solution export. When the tool extracts a CRM solution, the customizations.xml and all related resources will be extracted into their component parts on disk. This allows you to browse through solution components on your file system rather than digging into the somewhat cryptic contents of the solution zip file. Once the SDK is downloaded, the tool can be found at SDKBinSolutionPackager.exe. Full SDK documentation on the tool can be found online at Solution Tools for Team Development, http://msdn.microsoft.com/en-us/library/jj602974(v=crm.5).aspx. This article includes full details on command line options and some scenarios for including the tool with source code control. As an example, an export of a baseline CRM 2011 instance will look like this: If you drill into the Account folder for under Entities, you will see the following: The Solution Packager utility extracted the individual entity XML sections into their own files, making it much easier to review.
Command line usage
Using the Solution Packager tool is straight forward, exporting with just a few command line parameters. In the example below, my default solution was exported to c:temp with the name Default_1_0.zip.
If you add a custom entity to the solution, it also shows in the folder structure. For example, I created a new custom entity called Widget and exported to a new solution file named Default_2_0.zip: Notice that the custom entity contains some additional information, such as the Form Xml and Saved Queries for the custom entity. Because they had not been modified from the default system values, the out of the box entities did not include the additional information when exported. The Solution Packager can take the same extract and repackage the contents into a valid CRM solution zip file, ready for reimport. For example, if we wanted to modify a label on an entity attribute, we could update the entity component Entity.xml file and repackage the solution for import. This seems like a bit overkill for such a simple task: you could simply use the form designer and re-export the solution.
Managing Change
But what if you had a LOT of deltas between two solutions? One approach is to use the Solution Packager to export two similar solutions and use a comparison tool to review differences. For example, I exported my solutions as Default_1_0.zip and Default_2_0.zip, and extracted both to C:temp. You can use the comparison tool within Visual Studio to review the differences between the two folders: And the results show the deltas between the two solutions You quickly see how many differences exist between the two exports with just the addition of A custom entity with one custom attribute. All additions within Default_2_0 show the new components related to the Widget entity, but you also see some deltas on Relationships.xml and Solution.xml. The Solution.xml will simply list the addition of the Widget entity but the Relationships.xml shows much more detail: This is still a relatively simple update to the solution. When more changes are made to entities and their solution components, you will better see the benefits of the tool. I have made some additional updates to the widget entity, added a javascript web resource and added a ribbon button to the original default solution. I then made some changes to the entities and re-exported for review, adding a new attribute, updating the ribbon, updating the javascript and updating the widget main form. We can now review exports of Default_2_0.zip and Default_3_0.zip. Notice that the number of deltas in the files has been reduced, meaning both solutions contained the same list of entities and resources. The core entities are unchanged and will not show up on our list of differences. This does not sound like a big deal until we remember that we no longer need to compare two large XML files, narrowing down our review to only those changed acomponents. But the deltas between files has increased. We can see that the javascript, main form, the entity and the entity ribbon have all changed. For example, we can see the new script action on the ribbon button: and the updates to the referenced javascript web resource and the widget main form has changed: Now that we can see the deltas between the individual components, you a few options depending on the scope of the changes. For example, if everything on the source should update the target as planned, you can just import the new customizations, such as from a developer instance to the master customizations instance. If your changes on the destination will be overwritten on import, you can merge the differences into the new customizations before import. For example, if you made an update to the master instance on a form and you know that it will be overwritten by the developer customizations. If the changes were so dramatic between the two instances, it may be best to simply step back and make the updates manually rather than merging and risking an overwrite of some critical work. No matter what option you choose, you now have a powerful tool in identifying the deltas and making the decision that works for your situation. As you can see from the simple example above, the deltas are pretty easy to review once broken into their individual components. We took the default solution and narrowed down the differences between essentially all available customizations with relative ease. As you add additional components, you will see these as well. For example, plugin assemblies will be exported into their component .dll files, although a diff tool will not likely show you much between the two. But a custom workflow will be exported as a .XAML file that you can reviewed via the text differencing tool. Though the Solution Packager will not perform differences and merges automatically, it can be an extremely useful tool when managing solution customizations across a development team.