Background

Not everybody has the same approach as we do (we make software solutions) while
working with the MS CRM platform. Therefore you cannot always expect to have a
perfect scenario where the blueprint of the solution is saved to the source
control and from a specific tag, it’s deployed to both the TEST and PROD
environments as a managed package. When we take over other consultancies soltions,
we usually see that they just deploy the Default solution to both TEST and
PROD as an unmananged package. There are a lot of reasons why this is not a
best practice, but lets try to keep this blogpost positive.

Another issue that we sometimes meet is that a customer wants to upgrade to a
newer version of MS CRM and they ask us if we can visualize how many changes
there are from their solution compared to a Vanilla from the version they want
to upgrade to.

Note: Vanilla is the name we use to denominate a MS CRM solution that is not
modified with any configurations or customizations. In other words, standard
out-of-the-box.

Back in the days, MS CRM 4.0, we had the Customization Comparison Utility
which could load two MS CRM customization files and provide a visualization in
order to see what the differences between the source and target are, if any:

This tool helped us a lot in the way that we could always point out to the
customer that they had once again made a change to PROD environment whithout
notifying us and therefore the change would be overwritten by the DEV package
when deployed.

It also gave us the possibility to export all the differences to an Excel
Spreadsheet, where it was a bit easier to make diagrams and other visualizations
for better customer understanding.

Diff of solutions

Because we missed this tool a lot we decided to implement the logic as
a module in Daxif in order to provide this functionality.

It’s very easy to use, lets take the example that we have just created a
solution, see previous How to Daxif, basic setup
blogpost, and we have now retrieved both the managed and unmananged solution
and stored them in our source control:

Note: The only difference is that the assembly was rebuilt before packaging,
therefore, even though there are no code differences, the hash code of the
binary changes due to compilation strategies (non-deterministic) and therefore
not producing the same binary.

Note: In order to get a better view of the summary .CSV file, just convert to
an Excel Spreadsheet, enable Data filters and apply the following filter on
Source (does not contain a dot, which exclude all files paths)