This error happened to me after a deployment. Here’s why and how to fix it.
Symptoms
On a Publish All, you get an error message (see below). Customizations are not applied. But, the Publish by entity is working.
“There was an error calculating dependencies for this component. Missing component id {0}.”
In my case, there was a second problem that helped me understand the bug. I was importing a solution with 4 entities, including 2 customs and 2 managed. The importation falled with a generic error message. I downloaded the log to find a Duplicate Key error. Strangely the error was after the entities and the views imported. That was nothing like I experienced before. What could of failed if the entities and the views were good?
So, I did a trace on the server (you can’t Online) and here’s what I found.
>Creating IDependencyHelper(Microsoft.Crm.ObjectModel.DependencyHelper) from Microsoft.Crm.ObjectModel [2017-05-25 11:01:56.702] Process: w3wp |Organization:bcda52b8-44d9-4e6f-ae2b-69302a240d6e |Thread: 165 |Category: Platform |User: 588e4823-37e4-47af-8634-ceb00f7ad3f4 |Level: Info |ReqId: e7a58d30-4fcd-4b62-be20-18faaa455989 | DependencyHelperBase.CreateDependencies ilOffset = 0xB
>Creating IDependencyCalculator(Microsoft.Crm.ObjectModel.CustomControlsDefaultConfigDependencyCalculator) from Microsoft.Crm.ObjectModel
>[2017-05-25 11:01:56.702] Process: w3wp |Organization:bcda52b8-44d9-4e6f-ae2b-69302a240d6e |Thread: 165 |Category: Platform.Sql |User: 588e4823-37e4-47af-8634-ceb00f7ad3f4 |Level: Verbose |ReqId: e7a58d30-4fcd-4b62-be20-18faaa455989 | DBCommandExecutor.ExecuteQuery ilOffset = 0x45
>SELECT [EntityId] AS [entityid] FROM [EntityAsIfPublishedView] WHERE (ObjectTypeCode = 10050)
That was it. The culprit was the entity with the object type code 10050. After, inspecting the customization.xml file inside the solution zip, I knew it was because of the custom controls.
Dynamics’ Architecture
What is a Custom Control (CC)? The CC were introduce in Dynamics 2013. They allow to add a different kind of controls in the mobiles forms. You can define them at an entity level (calendar, editable grids) or inside a form (sliders). Look here for more details.
In the database, there is a link between these controls and the entities:
SELECT [PrimaryEntityTypeCode], [CustomControlDefaultConfigId], [ControlDescriptionXML] FROM [CustomControlDefaultConfigBase] ORDER BY 1
Even if you never willingly configured them, they will end-up in your solution. Why? Because at the creation of an entity, Dynamics creates a record in the table CustomControlDefaultConfigBase. Then, when the exportation process detects a custom control config, it dumps it in the solution xml. It’s one the things I’d like to choose to export or not.
<CustomControlDefaultConfigs>
<CustomControlDefaultConfig>
<PrimaryEntityTypeCode>10050</PrimaryEntityTypeCode>
<CustomControlDefaultConfigId>{e3e82662-d6b8-e611-80c2-005056863441}</CustomControlDefaultConfigId>
<ControlDescriptionXML>
<controlDescriptions />
</ControlDescriptionXML>
<IntroducedVersion>1.0.0.98</IntroducedVersion>
</CustomControlDefaultConfig>
</CustomControlDefaultConfigs>
Resolution
As a temporary solution, you can replace the tag inside the solution zip by <CustomControlDefaultConfigs/>, rezip and import.
First possible fix is to rebuild your base development environment (Master) with a copy of your production. Why? In a addition to a unique name, every entity has unique code generated by the database. Commonly called the Object Type Code. Those are hard-coded for the managed entities like account, contact and opportunity. But generated for the rest starting at 10 000. From what I understand, it’s simply the primary key of the entity table. Here lies the problem.
When imported in another environment, the solution will contains every details the CRM needs to recreate the entity. Including the unique name and the object type code. Since the code is generated by the primary key of the table, it cannot be overriden. From this we can deduce, that if you create two entities and create them in another environment, they might not be assigned the same code.
This is actually a common issue. CRM usually replace the code when importing by comparing the unique name. In this case, the custom control directly compare the code found in the solution with the code found in CustomControlDefaultConfigBase.
By copying replacing your master by your production, you’ll have the same codes. But it won’t prevent the problem from happening again. I trust that Microsoft will release a patch for that in the future.
Second possible fix is to delete the custom control configuration in your master. No config to compare. No problem. Of course, this is highly unsupported. Hopefuly for you, I did several tests and research. No other components reference this.
I recommend this if you don’t use the mobile yet.
delete from [CustomControlDefaultConfigBase] where PrimaryEntityTypeCode in ( 10009,10023,10050,10038 )
Source: https://crmtipoftheday.com/2017/04/14/missing-component-id-0-error-when-publishing-customizations/