Unanswered

Deployment using Azure DevOps - Failing due to 'The reason given was: AttributeId is null'

(0) Share

Report

Posted on by Community Power Pla...

I have a solution which contains several objects such as a Canvas App, Model Driven App and several flows and is based in Dataverse.

To move these to our testing environment we use a very simple Pipeline in DevOps.

This pipeline exports the solution and writes to source control, then uses that to build an artefact that is then used to import as a managed solution to the test environment.

Up until now this has worked solidly and issues that have arisen have been resolved due to error messages giving appropriate information.

However, following our current deployment we have received the error 'The reason given was: AttributeId is null' there seems to be no context to ascertain where this AttributeId is located. I have tried to manually export from our dev environment and import to test but get the same error.

I am reaching out in case anyone has experienced similar issues in the hope that they can either shed some light on where this coming from or at least give me a lead.

Thanks in advance.

Categories:

Governance & administering

I have the same question (0)

All responses (2)

Answers (0)

Linn Zaw Win 2,996 on at

Like (0)

Report
There are a few threads with similar error messages. Have you checked out those threads to see if any of the solutions are relevant to your situation? (such as deleting the relationship recently, etc.)
When you manually export from our dev environment and import to test and get the same error, can you download the error log .XML file and open it in Excel to see at which component it is throwing that error?

https://powerusers.microsoft.com/t5/Microsoft-Dataverse/Error-when-importing-solution-EntityId-is-null/td-p/1188194
https://www.reddit.com/r/Dynamics365/comments/m6c5cd/error_when_importing_solution_to_production/
https://powerusers.microsoft.com/t5/Microsoft-Dataverse/Multiple-developers-sharing-work-on-multiple-Solutions-using-ALM/m-p/2133382#M29538%3F

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (1)

Report

@Anonymous I seem to recall seeing the same/similar error when we've deleted a column in our development environment and created it as a different type of column but used the same schema/logical name as the original column. If I remember correctly this yielded this error when the target environment had the original field deployed to it previously.

The solution was to delete the column and recreate it with a new schema/logical name. Or alternatively install an intermediary version of the solution first to the target environment which contains neither the original column, nor the new column. Then after that you can deploy the newer version with the new column

Was this reply helpful? Yes No