Apply Upgrade fails - blank dependency list

[AndersLindstrom]

I removed a table from an environment and wanted to push that to the TEST environment, but after a successful installation in the TEST environment, the apply upgrade failed with a blank dependency list. I contacted Microsoft support about it, and they said that it fails to remove the previous solution because of a reference in the Model Based App that we use. However, the table is not a part of the Model Based App and the Model Based App is a part of the new installed solution which should be clean of references to the removed table. All our customizations are in this one solution (except for Service Endpoints and Entity images).
It has been escalated to second tier Microsoft support, but I haven't heard anything since last Thursday.
This seems like a bug, because the only way (?) to get around this issue, seems to be to uninstall the solution. This will cause data loss if there are newly added fields and entities in the upgraded solution. This is the first project that I have used managed solutions and up until this incident it has been working great, but this makes me pause a bit. I am posting here to hear about others who have had this experience.
Is the best practice to make sure to patch all additive customizations before removing any table in an upgrade, i.e., any removed relations or tables should be in controlled small upgrade?

Empty dependency list

[cchannon]

I would say that "best practice" for avoiding solution upgrade conflicts is a big category, but would include (at a minimum):

• Checking your solution.xml after exporting to make sure you haven't accidentally exported unintended dependencies
• Checking your solution layers in the target application for any unmanaged customizations that could cause conflicts
• Ensuring you are never managing multiple unmanaged solutions in one environment; especially where one or more are intended to be exported as managed

But I don't feel that breaking up your solution into additive and subtractive imports is really necessary.

I suggest you start with bullet 1 above. Look at your solution.xml file inside the solution zip and scroll down to the bottom to see whether you have any unresolved dependencies in this solution. If not, then move on to bullet 2: look at the table you're removing in the target environment and see if it has any unmanaged customizations that would create dependencies.

[AndersLindstrom]

Thank you for your reply!

Regarding your points:

1. The table that was causing the upgrade to fail (according to Microsoft) was the table that I removed from the DEV environment (i.e., Delete and not remove from solution). When I exported that solution, there could not be any references to that table anymore, because it was not there.
2. The target environment only have managed solutions, and it only has the application that we are working on. The table that was removed, was only contained in that managed solution that I was trying to upgrade.
3. We only have one solution for the application (granted I have the service endpoints and SVG-files in a separate solution, but those does not have any dependencies the other way)

Anyway, I didn't intend this post to be about AML in general, because that is a big topic, but more to figure out if others have hit the same issue with a table removal that fails in this way, and if so, how to avoid it. Microsoft said that I should remove references from the AppModule in the target environment, which I can't, since it is managed and contained only in the solution that I am trying to upgrade. I ended up uninstalling the solution, and then I exported the missing table from another DEV-environment, and then I managed to get it running again. I will see if I will be able to remove that table sometime in the future. 

Thanks for your input. Based on the few responses, it seems like it is a rare issue that I have encountered, which is encouraging.