Solution Component types in Dynamics 365

CRM 2016 brought one great improvement – possibility to choose what subcomponents we want to include in the solution. We can choose single fields, views or relationships for an entity. Previously when an entity has been added to a solution, all its subcomponents were automatically added to this solution. This great feature allows to better control what is transferred between environments. Who has never imported a view or some chart that was changed on testing environment to live environment, by accident, please raise your hand. Currently we can include only the components that were changed and make sure nothing else will come along. Of course, it requires changing the mindset – quite recently I was asking a many-year CRM customizer, why he has added all components for Account entity to our solution, if the only thing that was changed were few added fields. “Because it always was like that” is not satisfying answer for me, as you probably already figured out 🙂

Because of this new feature, I believe that it’s important to better understand what is in fact kept in the solution from the metadata and data perspective. Every element in a solution is called Solution Component. It’s a simple entity that has a type and few values that help identify it (like ObjectId) if it’s a metadata or data component and if it includes all Subcomponents, does not include subcomponents or is only a shell of a component. Documentation on MSDN (https://msdn.microsoft.com/en-us/library/mt608054.aspx) clearily defines all solution component types, and the most important fields, which are:

• componenttype: The object type code of the component.
• ismetadata:  Indicates whether this component is metadata or data. (1 : Metadata, 0 : Data)
• objectid: Unique identifier of the object with which the component is associated
• rootcomponentbehavior: Indicates the include behavior of the root component (0 : Include Subcomponents, 1 : Do not include subcomponents, 2 : Include As Shell Only)
• rootsolutioncomponentid: The parent ID of the subcomponent, which will be a root

I researched all available solution components. Below you can find a summary of their names, logical names, short description and how to get them using SDK. Basically there are three ways of getting this data using SDK:

1. Using dedicated OrganizationRequest: for example EntityMetadata, AttributeMetadata etc
2. Using RetrieveRequest (or simply IOrganizationService Retrieve message)
3. Using RetrieveMultiple specifying QueryExpression with proper entity name and id equal to ObjectId from Solution Component object. Don’t ask me why simple Retrieve does not work for this components – it simply does not.

Interesting thing is that some components are known as not-transferable through solution (like Duplicate Detection Rules). I will try to investigate in the future if it’s possible to add them to the solution using SDK and successfully transfer to another environment using solution.

UPDATE: I investigated if it’s possible to add a solution component that is listed below, but it’s not available through UI, so for example Duplicate Detection Rule:

var solutionComponentRequest = new AddSolutionComponentRequest()
{
    ComponentType = 44,
    ComponentId = duplicateRule.Id,
    SolutionUniqueName = "solutionName"
};
 
service.Execute(solutionComponentRequest);

Unfortunately such operation ends with with an exception:

An unhandled exception of type 'System.ServiceModel.FaultException`1' occurred in Microsoft.Xrm.Tooling.Connector.dll
Additional information: Invalid component type provided 44

Solution components summary: