You’re offline. This is a read only version of the page.
Hi everyone
I have a theoretical question regarding the layer of managed solutions and what to expect after import. I don't want to proceed with deploying until I understand the consequences. For complicated reasons, I cannot use patches or Upgrade solutions.
Lets say I have a managed solution called managed solution 'A' which contains entities 'Ex', 'Ey' and 'Ez' installed in an environemnt
Then I create another solution in my development environment (not a patch or an upgrade, but a separate solution called 'B'). I then include the same entities 'Ex' and 'Ey' with some field additions and field deletions but do not include entity 'Ez'.
If I then export solution B as managed and import as a new solution in the test environment (which has managed solution A already), what will the outcome be?
Will I have 'Ex' and 'Ey' with the latest changes from solution B and 'Ez' will still exist from solution A? How does Solution B know to overwrite the existing entities 'Ex' and 'Ey' if it is not a patch or an update and is just a separate managed solution with different fields? Is it because the entities have the same underlying unique GUID values and the changes that I will see are simply the ones from the most recently published solution? Or maybe I will have 2 versions of Ex, 2 versions of Ey and 1 of Ez?
I would also like to know if Solution A contained entity Ez and Solution B contained entity Ez too but with 50 new fields and with 10 fields deleted, will the most recent published changes have the 50 new fields from B + the original 10 fields from solution A still (or will those 10 fields be deleted after published solution B)? Most importantly, what happens if the entity Ez in solution B causes the form to go over the 1024 field limit, assuming the fields are comibined on the form?
Thank you all for your guidance
C
Hi Colm,
Thank you for the post.
I know solutions layering is not a very easy topic to understand, therefore I will try to explain it as good as I can below in blue:
"Lets say I have a managed solution called managed solution 'A' which contains entities 'Ex', 'Ey' and 'Ez' installed in an environemnt"
Solution A=Ex+Ey+Ez
"Then I create another solution in my development environment (not a patch or an upgrade, but a separate solution called 'B'). I then include the same entities 'Ex' and 'Ey' with some field additions and field deletions but do not include entity 'Ez'."
Solution B= Ex+Ey+some other Ey fields-some Ey fields
Until now if you import solution A first and you don't upgrade it in order to have the Ey fields removed, those that are not part of solution B they will remain in the system, even if the Solution B does not have them as solution A already has them.
"Will I have 'Ex' and 'Ey' with the latest changes from solution B and 'Ez' will still exist from solution A? How does Solution B know to overwrite the existing entities 'Ex' and 'Ey' if it is not a patch or an update and is just a separate managed solution with different fields? Is it because the entities have the same underlying unique GUID values and the changes that I will see are simply the ones from the most recently published solution? Or maybe I will have 2 versions of Ex, 2 versions of Ey and 1 of Ez? "
All changes from solution A together with those changes from solution B will remain in the system unless you want to upgrade or delete solution A.
When we are discussing about layers they are independent on each other and one solution won't be able to delete changes produced by another solution unless we are discussing about holding solution and its clone.
For fields deletion you must use upgrade process for solution A or if you don't need the rest of the changes solution A introduced in the system, you can delete it and this will delete the fields as well.
Patches don't support delete operation, this is already documented.
The entities will not be exported in the customizations.xml based on their GUIDs and the entity and field GUIDs will not be exposed in the solution file, instead we are working based on schema name.
If you have more than one layer for each component, things get a little bit harder to understand, as every change you perform in the source environment for your solution, needs to be handled component by component, for those performing top wins, for example a change of property will be reflected if you update it on the layer on top, like an audit setting on the field definition, however if your goal is to delete the component, adding another layer with the same entity and removing the fields won't work.
For components performing merge, like forms, sitemaps, optionset values and App Modules in order to see any change you need to perform solution upgrade for all layers.
To respond to your question, adding a new layer is not powerful enough to delete fields, it is just powerful enough to change properties for components performing top wins.
"If I then export solution B as managed and import as a new solution in the test environment (which has managed solution A already), what will the outcome be?"
You will end up in your target system with the following:
- Solution A and all its components
- solution B with all its components
With this in mind solution A's fields and solution B's fields together with Entity Ez will still be there in the system.
"I would also like to know if Solution A contained entity Ez and Solution B contained entity Ez too but with 50 new fields and with 10 fields deleted, will the most recent published changes have the 50 new fields from B + the original 10 fields from solution A still (or will those 10 fields be deleted after published solution B)? Most importantly, what happens if the entity Ez in solution B causes the form to go over the 1024 field limit, assuming the fields are comibined on the form?"
Only solution A is able to delete the fields it introduced previously, in order to do this you have two options:
a. use the approach I suggested on the other thread with clone: https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/395905/the-field-cannot-be-created-because-the-maximum-number-of-fields-for-this-entity-has-been-reached
b. If you no longer need Ez and the data behind it you can simply delete solution A
If your solution B causes you to reach the fields limit, the only way to mitigate this will be by upgrading solution A in order to have the unwanted fields removed, the detailed steps of this upgrade depend on the possible errors you might face, but in theory they are very similar with those below:
1. Go to the DEV or source system of solution A
2. Settings->Solutions and select solution A, after that clone solution
3. Go to the affected entity and make sure you do not have the fields you no longer want in there, if they are there please remove them from the solution or make sure you don't have dependencies on them and delete them, keeping in mind for the dependencies you might need to fix the dependencies with a first solution upgrade and after that perform the field deletion with a second solution upgrade
4. Export the solution as managed
5. Import it on the affected environment with the default settings of upgrade and maintain customizations
Once this import will be done your fields will be removed.
I hope this clarifies the behaviour of solution layering in the context of fields deletion.
If you have questions please don't hesitate to reply back.
Thank you!
Share
Report
All responses (
Answers (
170
