Hi PS,
Thank you for posting this detailed description.
I will start by analyzing everything you wrote in order to explain what will happen overall with this process, the answer is not as easy to understand and not as straight forward as you might think.
"In DEV i have :Base Solution -> Patch 1 -> patch 2
In Live i have: Base Solution
Patch 1: Components:New Entity B and old Entity A. For entity A changed the form to show a Tab and included fields from entity B (Cannot be imported into Production since there is more work to be done, testing etc pending)"
Base solution, or holding solution is already in DEV and Production
Patch 1 contains an entity B
Patch 2 contains an entity A, which probably is part of the holding solution, or any other solution available in Production environment already, but in this patch 2 you included, most probably some lookups for the entity B, in this regard, unless you will bring the entity B inside your solution and the associated relationships, importing patch B will generate dependency issues.
What you can do to avoid the dependencies issues, in case you really have both sets of changes in the same form, is something similar with what I described below:
- while having a form linked with relationships between one entity and the other, as lookup fields or as navigations on the left side of the form, the system will require both sides of the relationships, the one from entity A and the one from entity B together with at least the entity as a shell and the system defined fields
- in order to avoid this you have multiple options, the easier one to implement is to have a second form as a copy of the existing one using save as functionality, but this process will require some work as you will need, once you are ready to deploy the changes associated with the entity from patch 1, to verify the layering and to upgrade the solutions which bring the old form
- the way you will work with the Save As functionality has the following points to be taken in consideration: on the existing form you will need to delete the fields which are part of the entity B as the entity B is not ready to be included in the solution, and remove the copy you just created from the patch
- once you will be ready to deploy those changes from the patch 1, your next step will be to disable the original form in your patch 1 and bring the copy you just created above
- also after you will bring the form with the fields associated with entity B, you have two options, depending on layering, one of them is to have both forms out of which the initial form will be disabled, but I can not guarantee this will work as it depends on layering, the second option will be instead of using patches, as an entity is the main component of the system, I will recommend you to clone your original solution and propagate your changes using the base solution, this way you can use the delete and promote functionality in order to delete the old form from that specific solution layer and also to avoid forgetting to bring the entity B in the base solution and the possible impact
You can think at other methods as well, keeping it mind all of those should take into consideration some main principle available below:
- forms merge
- forms layering dictates the end state of the form, if the initial form remains active on the system you might think about checking its layering and upgrading your solution files which will bring the layers in order to make it disabled
- bringing components which are not ready into the system should be discussed component by component in order to evaluate what is the best approach for each component
- additionally, there has been few months ago a change, not sure if that is still active or not, but this change will not allow you to import in your system a lower version of your solution, in this case if the patch 1 has its build or release version lower than the existing patch 2, you will need to increase them before importing them after patch 2
- unless you will perform an upgrade with a higher version of the base solution you already have, the deletion of the current components is blocked by the patches, more details about it in the link below:
https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/create-patches-simplify-solution-updates#patches
To respond to your question, as long as you can not remove the entity B fields from the entity A form, you will need to work your way around the dependencies.
I hope this helps
