Solution failed to import: Solution Upgrade action failed after import as holding. InnerException is: Solution dependencies exist, cannot uninstall.

[Jsalaz1989]

Hi,

I'm trying to understand how to import an updated solution, but I tend to run into this same error with different projects.

Initially, I imported my solution from my dev environment to my prod environment as a managed solution. Then, I modified my dev solution, which includes removing an environment variable that is no longer necessary. When I try to import this updated solution into prod, I choose the Upgrade option:

This option explicitly states that "any objects not present in the newest solution will be deleted". Yes, that is precisely what I'm hoping for, I don't want to see that old environment variable in prod, since it is no longer necessary.

However, when I try to upgrade, I get this error:

As far as I understand, it's complaining that "Solution dependencies exist, cannot uninstall." and specifically mentions a certain EnvironmentVariableDefinition. But isn't that exactly what Upgrade claimed to do? I know that variable currently exists, the whole point is to detect that it exists in prod but not in dev and therefore get rid of it.

You can also see that it creates a new solution, tacking on "_Upgrade" to the name, instead of replacing the old one.

This has happened often with other solutions so in prod I just end up erasing the old solution and importing the new one as if it were the first time prod ever sees this solution. However, this doesn't feel right. There is either something I'm misunderstanding about the Upgrade option, or something is not working right on Microsoft's side. Maybe I should always be using Update instead, idk, but it's not clear by the import wizard.

Also, in time I would like to automate this headache-y and manual devops flow I currently use (there are other issues or quirks that arise when doing this manually it seems). Perhaps when I do get some ALM going, then this error will no longer appear, but for now I would really like to understand what's happening as I step through this manually.

Thanks

[Nievechica24]

I am getting the exact same error. Am I importing the solution incorrectly or is this a known issue?

[mikael_andersen]

@Jsalaz1989 Running into the same issue however for us it's dropping a column.

Did you find a solution or are we left with deleting the solution first - that seems very wrong to me.

As a side note we have ALM up and running, but that makes not difference. Actually fails more often than manually exporting and importing.

[Jsalaz1989]

I have not found a better workaround than deleting the prod solution and re-importing it. I agree that it seems quite wrong.
And of course we get no input from Microsoft here. I've even tried contacting our company's MS support people directly and they just ignored me. And that Tata Consultancy group they use was copied as well, but nobody replied.

[sdholbrook3]

Having the same problem today. Anyone know a workaround? 

[Daved5]

I am having the same problem.  I am nervous to delete the Solution in Production.  I assume, that this will not delete the tables that are part of the solution ?  Can someone confirm that i will not lose the data in the tables of the solution in production ?

[mikael_andersen]

@Daved5 You should be nervous. If you uninstall/delete the solution that data will be lost, so in most cases is not an option. See this link https://learn.microsoft.com/en-us/power-platform/alm/maintain-managed-solutions where they state below:

[Nievechica24]

After working with Microsoft Support, they had us delete the existing solution, go into the solution called "Default Solution" within that environment, delete all of the connection references and custom connector connections we had and then re-import. It worked for us after that. Not sure if this would help you.

[mikael_andersen]

We also engaged with Microsoft support and they ended up running some scripts to delete attribute maps that caused some kind of circular dependency. Below is what they wrote as a hint to avoid it in the future.

--- From Microsoft support ----

Cause:

An attribute mapping was present in source and target both as unmanaged / as part of the active layer; expectation was that in target the component is managed. And since we cannot delete the attribute mappings directly from UI, the only way found to delete it from target was through a script mitigation.

Mitigation:

Run custom mitigation scripts to: delete the entity map for the 2 entities, delete the 2 entity relationships and then proceed with deleting the lookup attribute.

Note:

In order to avoid this from happening in the future we recommend to refrain from creating/importing unmanaged attribute mappings in target (in a managed environment). What we saw was a very particular situation where an attribute mapping was present in source and target both as unmanaged / as part of the active layer; expectation was that in target the component is managed. And since we cannot delete the attribute mappings directly from UI, the only was found to delete it from target was the above method – script mitigation.

-----

Hope this can help others in a similar situation.

[mikael_andersen]

We also engaged with Microsoft support and they ended up running some scripts to delete attribute maps that caused some kind of circular dependency. Below is what they wrote as a hint to avoid it in the future.

--- From Microsoft support ----

Cause:

An attribute mapping was present in source and target both as unmanaged / as part of the active layer; expectation was that in target the component is managed. And since we cannot delete the attribute mappings directly from UI, the only way found to delete it from target was through a script mitigation.

Mitigation:

Run custom mitigation scripts to: delete the entity map for the 2 entities, delete the 2 entity relationships and then proceed with deleting the lookup attribute.

Note:

In order to avoid this from happening in the future we recommend to refrain from creating/importing unmanaged attribute mappings in target (in a managed environment). What we saw was a very particular situation where an attribute mapping was present in source and target both as unmanaged / as part of the active layer; expectation was that in target the component is managed. And since we cannot delete the attribute mappings directly from UI, the only was found to delete it from target was the above method – script mitigation.

-----

Hope this can help others in a similar situation.