In CRM 2011 there are two approaches you can use to create solutions; Managed and unmanaged. There is lots of information available as to what the differences are, for example on channel 9. In general I would recommend using managed solutions every time you are exporting customizations from one environment to the next (in a dev, test, prod environment). But this article specifically addresses the development of applications/products using multiple solutions. I have seen various approached used and people running into problems caused by developing multiple unmanaged solutions in one organization.
You can split a solution into multiple solutions for various reasons. The basic reasons typically being the ability to install only the components that are needed and the second being the reuse or sharing of components in different applications. The simplest way to create these solutions would be to create a single CRM development organization create multiple unmanaged solutions and export these as managed to create an installation package. With this approach there is a good chance that you will either run into problems with dependencies when installing the (managed) solution or uninstalling them. This is because of the difference in behaviour of CRM between managed and unmanaged solutions.
Try the following:
When you compare the two files you will see that the unmanaged customizations contains all the attributes defined on the lead entity including the new_field attribute. The managed customizations file however does contain the lead entity but only has the new_field attribute, the existing (managed) attributes are not included. Managed solutions include references to components used from other managed solutions, of course filtered by the components included in the solution. In this regard it does not matter if the components are in a managed solution you created or the default solution. The default solution is itself a managed solution, but does behave slightly different from other managed solutions.
Let’s examine a simplified application that will consist of two components.
Solution A: should contain a custom entity new_A with a lookup field new_Aid on the lead entity
Solution B: should contain a custom entity new_B with a lookup field new_Bid on the lead entity
First we will use one CRM organization to create both the packages. Do the following:
When you export the solutions as managed the customization files for both solutions will contain both the relation for new_Aid and new_Bid on the lead entity. Note that for relations CRM does not include attributes but only the relationship. During import CRM will give show an error that solution A cannot be import because entity B does not exist and solution B cannot be imported because entity A does not exist. In this situation CRM will give a warning during the export of the solutions that components B and A must exists prior to installation of the solution or the import will fail, but still allow export of the solution. More importantly there are more complex scenarios conceivable were CRM will allow you to export the solutions to managed and import the solutions on the target environment. But when you want delete one of the solutions this may fail because of a dependency.
Now I go through the same example but limiting it to one unmanaged solution per organization. This will mean that because we are creating two solutions you will need two CRM organizations. With the multi-tenancy on CRM this is no problem we can simply create two organizations on the same server. If you are using CRM online or CRM hosted getting additional organizations is possible but typically more costly.
Let’s follow the multi organization approach.
Now you can import solution A and then B into your target organization and remove them in the reverse order without any problems. When you try to install or uninstall solution in a different order CRM will give an error when you upload the package, you will not be able to upload the packages. The error message does include the components that are missing and the solution in which they are located.
If you compare the customizations files and specifically the entity new_A in the managed solution A and managed solution B you will see that solution B contains far less details, for example the FormXml and SavedQueries are not included. The other important file in this is the solution xml file. This contains a list of missing dependencies, this is a listing of all the components that must be installed prior to installing this solution.
Another interesting thing is that if you do not add entity new_A to solution B CRM will give a warning during export. In this example this warning can be ignored but you should add new_A to the solution. If you do not and make changes to new_A they will not be included. CRM may also fail import if one of the unmanaged components in solution B is dependent on new_A. CRM does not detect this difference during export but will during import and the import will fail. If there are no dependencies you can choose not to include new_A you can import the solution without any problems.
The example given in this article uses a very simple and only uses a lookup attribute/relationship. But the same applies to other components such as a workflow calling another managed workflow or plugin steps registered on a managed plugin type.
Do keep in mind that uninstalling a solution that has dependencies from other managed or unmanaged solutions is not possible. Updates on solutions are interesting as they are additive only, but this is an area for another time.
When you are using this approach you will have some additional steps in building an installation packaged or possibly even debugging. For example if you have a plugin in a base solution which has to change because you found a bug in a dependent solution this will mean that you will have to update your base solution export then import this to you dependent solutions organization before you can test it. If you have more than two layers this will mean more steps. There are tools available to simplify this such as the Developer Toolkit for Microsoft Dynamics CRM.
Limiting yourself to one unmanaged solution avoids problems with dependencies when installing or uninstalling solutions. This specifically applies to development of multi components solutions but also when developing multiple solutions.