Developer 101: Walkthrough – 2 independent solutions, dependent on same custom entity relation

Spoiler alert: Seasoned CRM developers can skip this article!

This article is intended for beginning CRM developers facing the situation, in which I ran today: dealing with two independent solutions that have to depend on the same entity relation.

Today I ran into this situation in which I had to implement a CRM entity relation within the solution I am working on. Nothing special one would say. However it turned out that the EntityReference I had to implement was also part of another solution. Both solutions have the appointment entity included. On both appointment entities the relation to the product entity has to be made.


Both solutions can be installed independently from each other, but they can also be installed together within the same CRM organization. When running both solutions on the same environment, was want to be sure that during the publish action only one product relation is present on the target system, but we also want to make sure that the script events attached to the field from both solutions are present.

CRM has a smart workaround to achieve this. In this article I’ll describe this workaround. 

Step 1

  • Make an unmanaged export of the solution in which the field already resides.
    Save the zipfile in a work folder.
  • Go to the work folder and extract the contents of the zip file.By now you should have at least 3 files:
    –  solution.xml
    –  [Content_Types].xml
    –  customizations.xml
  • Edit the customizations.xml in an editor (e.g. Notepad++)
    Strip all entities, RibbonXml, Roles, Workflows, Field security profiles, EntityMaps, and entity relations you don’t need.
    Be careful not to break the xml. In my case, my xml only contained the “appointment” Entity and a single EntityRelationShip “product_appointment”.
  • In the remaining parts, strip every line that you don’t need.
    Not really needed, but heh…. it is nicer.
  • Save the customizations.xmlThe file should look like this:

Step 2

  • Edit the solution.xml in an editor (e.g. Notepad++).
  • Set the UniqueName attribute to a new name, e.g. “AppointmentImport”.
  • Clear the MissingDependencies. Only the tags <MissingDependencies></MissingDependencies> should remain.
  • Clear the RootComponents, just leave the components in you need.
    In case you miss one of the rootcomponents, your import will fail.
  • Save the solution.xmlThe file should look like this:Solutionxml

Step 3

  • Edit the [Content_Types].xml in an editor (e.g. Notepad++).
  • Clear almost any contents, make sure the only remaining content types are XML and XAML
  • Save the [Content_Types].xml
    The file should look like this (otherwise the import will fail):Contenttypesxml

Step 4

  • Make a copy of the exported solution zip file, and rename it.
  • Open the renamed zip file using 7ZIP (standard Windows explorer zip will mess up your solution).
  • Drag the changed files to the in 7ZIP opened file
  • Close the solution zip file

Time to import!

The altered solution file can be imported into the CRM organization.

In case the import fails, make sure you download the import error log xml file. Drag this file into Excel, and you will be presented with a detailed overview of the error encountered during the import. See example below.


Once imported: Publish the changes!
The new relationship becomes available (the lookup field appears in the entity. From there you can remove the imported solution file and go on with your modifications.

The great thing of doing the modification this way, is that it doesn’t matter for the entity and the relationship what solution is installed in the organization; my solution, solutionX or both solutions. The relationship will be there and will be used with all modifications from both solutionX and my solution.

Another job done.