Skip to main content
Dynamics 365 Community / Forums / Sales forum / Importing a patch solu...
Sales forum
Answered

Importing a patch solution

editSubscribe (0) ShareShare
ReportReport
Posted on by 426

Hi All, 

I have a question about patch solutions being imported in live as out of sequence. 

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)

Patch 2: requires a quick change to Entity A form which is to add a field and to be promoted in Production asap. 

My question is:

Since Patch 2 has same component as in Patch 1 it contains the new changes which are not due to go Live how can this be avoided so i can just promote my only change under Patch 2.

I know sequencing is not an issue i can import Patch 2 before patch 1 the issue is with how to avoid the changes under Patch 1.

I thought if i hide the tab in Patch 2 that has been created in patch 1, that might help and later make it visible again when Patch 1 gets imported,  but my worry is on this tab i have fields from new entity B which would require to add dependant components etc and i cant think how this is gonna work too risky as it is going to be straight in Production. 

And are other environments are quite muddled up and not good to check anything, so please pour in any suggestions on how to achieve this. 

Thanks,

PS

  • PS10 Profile Picture
    PS10 426 on at
    RE: Importing a patch solution

    Thank you Madalina for your response.

  • Verified answer
    RE: Importing a patch solution

    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

Helpful resources

Quick Links

What Motivates a Super User?

We know many of you visit the Dynamics 365 Community and Power Platform…

Demystifying Copilot with Georg Glantschnig…

Industry experts answer burning questions directly from our amazing Community…

Setting Up Knowledge Sources for Copilot…

Look at how configuring a comprehensive knowledge base is crucial…

Leaderboard

#1
Andre Arnaud de Calavon Profile Picture

Andre Arnaud de Cal... 283,045 Super User

#2
Martin Dráb Profile Picture

Martin Dráb 222,570 Super User

#3
nmaenpaa Profile Picture

nmaenpaa 101,138

Product updates

Dynamics 365 release plans