Transfer of attribute to another environment fails

[jonckhje]

Dear friends, readers,

today I was rather startled by our Dynamics (CS in this case). 
When transporting our base environment from DEV to Testing, system returns:

The uninstall operation will delete the base layer for the 
component 'Attribute' with id '4e57afc6-2fe4-42dd-ab82-7f1b869a3861' and name 'edsn_categorie'. 

The operation cannot continue because there are other managed layers over the base layer. 
You can use the solution layers to find out which other solutions are blocking the operation.

The message is correct. The field is already present in the system in a managed solution, but that's the same solution as I'm trying to import. There is literarily no reason why it should be deleted.

When looking at the attribute now, ofcourse there is another layer on top of it, which is the _Upgrade solution layer.

I'm lost for now. 

Any thoughts?

Thanks a million!
Regards,
Jeroen

[marimourao]

The exactly same thing is happening with me and I don't find a solution

[jonckhje]

Okay, I'll break up what we did so far, maybe it can help you (and/or me).

The background of this action is that we're using a rather large solution for transfer our base customizations. This solution has grown too large in time and there are a few entities for which "all assets" was checked on adding them. This causes potential problem if Microsoft pushes service updates.

So, we started of to alter the solutions so that only custom fields and forms where included.

For the particular erroneous attribute, I did remove quite some fields from the solution that where completely OOTB and hence already present in the base solution of (in our case) CS.

The first time we tried to transfer the new lean-and-mean solution, the above error occurred.

I found out that adding all fields (that I removed earlier) back into the entity solution enables us to transfer the solution. That's nice so our other customizations can be delivered.
But still leaves me with the urge to slender my solution and get rid of OOTB fields. It's a nice to have, that I do realise.

What I found also, is that the GUID of this particular attribute in the target environment differs from the GUID of the source environment. It looks as if the attribute was deleted and re-added in the source environment, but I'm 100% positively sure that isn't the case.

Hope this may be of any help to you.

[davidyc]

Did you ever find a solution to this? @jonckhje 

[jonckhje]

@davidyc Unfortunately I haven't. The solution (partially) remains as uncomfortable big.

We did switch to using patches though. That's some kind of solution, I guess, but probably not what you're looking for.

[davidyc]

I have resolved the issue I was having. I had the exact same error message as mentioned on the original post for this thread. In my case the attribute mentioned in the error message was a lookup column. The issue had started after removing the table with the lookup and re-adding to my solution, excluding just one relationship which related to another table not in the solution. When exporting the solution after this change, a relationship (the one responsible for the lookup column mentioned in the error) that was included in the solution was not appearing in customisations.xml file. Therefore, the target environment was trying to delete the lookup column since the relationship for the lookup was not present. After removing both tables and re-adding in the source, publishing all changes and exporting for the target, the issue persisted. I would say that this was a bug in the system that should not have happened and that there was no action taken incorrectly was directly responsible. Anyway, the solution was removing both entities in the source environment, publishing all customisations, re-adding the entity that contained the lookup, publish all customisations, then re-add the parent entity (the one the first entity is looking up to) and publishing all customisations, export and check the customisations.xml to find the relationship is now present. Therefore, the solution appears to be a combination of the order in which the 2 entities were added into the source solution (after having made a small change to one of the entities) AND  publishing all customisations after every change.

Unfortunately, I don't know exactly what was happening behind the scenes but the error is gone and I was able to complete the import. I have wondered before whether the order in which components are added to a solution impacts how the system is 'aware' of dependencies, but I've not found anything conclusively on that topic. If anyone reading understands this better, I would appreciate your thoughts on it.

[aschmidt11]

Thanks a lot, just followed your workaround and it worked here. 🙂