Umbraco DataType / FieldType conflict when deploying between Umbraco Cloud Environments

Recently on a clients website I encountered an issue when deploying between Umbraco Cloud environments it would throw a rather unhelpful error message:

Umbraco.Core.Exceptions.BootFailedException: Boot failed. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation

From some trial and error, I managed to trace the error to some custom code installed on the site, this custom code added a FieldType to Umbraco Forms.

Due to the way Umbraco Deploy works, the DLL is deployed before the UDA files are run against the site, this means that the FieldType has already been created in Umbraco with a different UDI, before the importer runs the changes in the UDA, which then causes the deployment (in my case the website) to fail, due to having duplicate data types registered against 1 ID.

This issue should only happen on an environment / site which has never had this DataType deployed to it before, however the below fix may work if it has already been deployed, and then become "out of sync".

So the fix which worked for me, was to copy the UDA file from my dev environment, as this contained the correct ID.
I then logged into the affected environment / site via Kudu, temporarily removed the DLL creating the DataType, and then deleted the DataType from the backoffice.
I then logged into Kudu, uploaded the UDA file I copied earlier into the following folder:


I then moved up a directory, and then ran the following code to import the DataType with the correct ID:

echo > deploy

Once that deployed successfully, I re-uploaded the earlier deleted DLL into the bin directory, and the site came singing back to life, and worked as desired again.

Once the UDI are common across all environments (in sync), this should not happen again.

So what we are doing here is basically, reversing the order in which Umbraco Deploy handles the deployment, by running the UDA file before the DLL is deployed, so that the correct ID is created on the environment.

Comments (0)