Sonoma Partners Microsoft CRM and Salesforce Blog

Compare Fields Across D365 Orgs to help Debug Solution Import Failures

Today's blog post was written by Matt Dearing, Principal Developer at Sonoma Partners.

When working with a solution it is common to make changes to customizations. Scenarios like an incorrect attribute data type that needs to be recreated are very common, especially early in development. Although it is easy to recreate attributes in a development environment, it can be challenging to import that solution into a target with a previous version of the solution. The import process may fail in the target organization with a generic error message. When this occurs, it is generally related to attributes being recreated. The following is a simple LINQPad script you can use to compare attributes in two different environments. It will print out any differences in casing of schema name or data type which are two of the more common reasons recreated attributes will cause a solution import to fail.

The script itself connects to two different CRM environments: a source where customization changes are made and a target for deploying the updated solution. The script scans the target to get all of the custom entities with a given prefix where the prefix matches that of the publisher for the solution. If the entity is new in source, there is no reason to compare it to target as it will not fail the import.

Next the script loops through the custom entities for the target environment capturing each entities attributes. Schema Name and Data Type are the two most important metadata properties to compare, so those are returned. If an attribute is deleted and recreated and the casing of the Schema Name does not match exactly, the solution import will fail. This is because CRM does a case sensitive comparison of attributes on solution import to determine if any attributes are new and should be created. It will see two attributes with differently cased schema names as two unique attributes, the failure will occur in the SQL database as two columns cannot have the same name. Unfortunately this won't show up in the solution import UI as a helpful error. The second more common failure is that the data type has changed. Maybe the attribute was an integer/whole number and should have been of type money, or it was a picklist and should have been a string. In that case the solution import will also fail when Schema Names match but data type differs.

Next the source environment is queried for its attributes to do the comparison. If the entity no longer exists in the source environment, an exception will be thrown and caught and printed to the screen. This would mean the entire entity no longer exists in the source environment, so there is no comparison that can be made.

Finally the comparisons are done by Schema Name and Type and any discrepancies are printed out to the screen. If the source attribute no longer exists, there is no need to compare.

Knowing the discrepancies in attributes between environments can help tremendously when attempting to figure out why a solution import is failing. Here is the full source code:

Let us know if you need any help or have any questions by commenting below.

New Call-to-action

Topics: Microsoft Dynamics 365