SBX - Search With Button

SBX - Forum Post Title

Label display name not updating when importing managed solution.

Microsoft Dynamics CRM Forum

James F asked a question on 4 Feb 2015 3:08 PM
My Badges

Question Status

Suggested Answer

I'm having an issue with a label name not changing when I import a managed solution with the change.

On my dev environments I've updated a label called "Contact" to "Admin Contact". I then published all the changes made and export the solution as a managed solution.

When I go to import the managed solution the label never updates to "Admin Contact". When I check the customizations.xml file I see the "Admin Contact" label in the system.

Does anyone know why the managed solution is not updating the label and how I can fix it?

Thanks

James F.

Reply
Mamatha Swamy responded on 4 Feb 2015 4:05 PM
My Badges
Suggested Answer
Marco Brizi responded on 19 Apr 2019 3:29 AM
My Badges
Suggested Answer

Hi James, 

I've just faced and resolved the same issue in my environment based on Dynamics 365 CE 9.1.

The issue is caused by the way in which the metadata associated to the changed label are written into the associated XML block.

When working in a base solution, that is a solution born from scratch or by cloning another one, the issue should not appear, neither for new fields added to the form nor for existing fields to which you go to change the label.

Instead the issue happens when you are working on a Patch Solution, changing the label to a field already existing in the form or that has been added to the form by a previous Patch Solution for the same Base Solution.

To understand how it works and how to fix it, you have to unpack your solution in a local folder unzipping the file manually, or using the SolutionPackager tool.

When you add a new field in a form, the XML block associated to the field will be similar to the one below:

Being a new field, the attribute "solutionaction" for the element "<cell>" representing the form's field will contain the value "Added". You could have changed the "description" for your label and this update will be correctly implemented in your target environment.

Let's suppose that later you go to create a Patch Solution for the same Base Solution, and you change the label for that field. Exporting the solution and unpacking the files, and observing the associated XML block you can see that the update to the label is in there and also the attribute "solutionaction" for the field will continue to contain the value "Added":

In some cases as this one presented, what is missing is the new attribute "solutionaction" set to "Modified" for the "<label>" element driving the change for the description of the label:

At this point is it possible editing manually the file in order to add the missing attribute, repackaging the solution and deploying it. In this way the change will be correctly implemented in the target environment.

Reply
Suggested Answer

Hi

There are a few reasons for this behavior.

01. The field on the Admin Contact form label was directly set on the form, if that is the case, if you change the field display name it won't be updated on the form because it was directly set on the form. If you set a label for a field on the form, this will override the display name. I normally remove the field from the form and import again or add the field again for it to get the display name displayed

02. If the above is not sure issue, you will simply have to remove and add the field again, save and publish

Reply
Marco Brizi responded on 19 Apr 2019 8:26 AM
My Badges
Suggested Answer

Hi Kokulan,

unfortunately removing and adding back again the field, in the context of the same Patch Solution, is not enough.

Below, you can see the Form status in my STAGING environment, after have applied the Patch Solution 1.1.3.0:

Based on the same Base Solution in DEV, I've prepared the Patch Solution 1.1.4.0, where I have removed the field "Address Phone" with label "Address Phone_Patch 1.1.3.0" and then added back the field, this time with label "Address Phone_Patch 1.1.4.0":

Then, I have exported the Patch Solution 1.1.4.0 as managed and imported in my STAGING environment.

As you can see, the field "Address Phone" has been duplicated, because removing and reinserting it into the Form has caused the creation of a new element with a new ID, if you observe the XML equivalent block:

This is the fragment associated to the field as specified by the Patch Solution 1.1.3.0:

This is the fragment associated to the field as specified by the Patch Solution 1.1.4.0:

In order to resolve this extra issue, I decided to try performing a double patching: with the first Patch Solution I wanted to remove the field, and with another Patch Solution I wanted to inserting back the field with a new label. It didn't work neither at first stage, because even though with Patch Solution 1.1.4.0 I had removed the field, this was continuing to appear into the form:

The last tried, that finally worked, has been consolidating all the patches into a Clone Solution. In this way, a major solution release is created, and the finally form design was as expected:

As a final consideration, I would say that if you want only to add new fields into forms, you can adopt the Patching Solution strategy. But if you are planning to perform changes to fields already available into the forms, then the Cloning Solution strategy should be the preferred way.

Regards,

Marco

Reply
Mamatha Swamy responded on 4 Feb 2015 4:05 PM
My Badges
Suggested Answer
Marco Brizi responded on 19 Apr 2019 3:29 AM
My Badges
Suggested Answer

Hi James, 

I've just faced and resolved the same issue in my environment based on Dynamics 365 CE 9.1.

The issue is caused by the way in which the metadata associated to the changed label are written into the associated XML block.

When working in a base solution, that is a solution born from scratch or by cloning another one, the issue should not appear, neither for new fields added to the form nor for existing fields to which you go to change the label.

Instead the issue happens when you are working on a Patch Solution, changing the label to a field already existing in the form or that has been added to the form by a previous Patch Solution for the same Base Solution.

To understand how it works and how to fix it, you have to unpack your solution in a local folder unzipping the file manually, or using the SolutionPackager tool.

When you add a new field in a form, the XML block associated to the field will be similar to the one below:

Being a new field, the attribute "solutionaction" for the element "<cell>" representing the form's field will contain the value "Added". You could have changed the "description" for your label and this update will be correctly implemented in your target environment.

Let's suppose that later you go to create a Patch Solution for the same Base Solution, and you change the label for that field. Exporting the solution and unpacking the files, and observing the associated XML block you can see that the update to the label is in there and also the attribute "solutionaction" for the field will continue to contain the value "Added":

In some cases as this one presented, what is missing is the new attribute "solutionaction" set to "Modified" for the "<label>" element driving the change for the description of the label:

At this point is it possible editing manually the file in order to add the missing attribute, repackaging the solution and deploying it. In this way the change will be correctly implemented in the target environment.

Reply
Suggested Answer

Hi

There are a few reasons for this behavior.

01. The field on the Admin Contact form label was directly set on the form, if that is the case, if you change the field display name it won't be updated on the form because it was directly set on the form. If you set a label for a field on the form, this will override the display name. I normally remove the field from the form and import again or add the field again for it to get the display name displayed

02. If the above is not sure issue, you will simply have to remove and add the field again, save and publish

Reply
Marco Brizi responded on 19 Apr 2019 8:26 AM
My Badges
Suggested Answer

Hi Kokulan,

unfortunately removing and adding back again the field, in the context of the same Patch Solution, is not enough.

Below, you can see the Form status in my STAGING environment, after have applied the Patch Solution 1.1.3.0:

Based on the same Base Solution in DEV, I've prepared the Patch Solution 1.1.4.0, where I have removed the field "Address Phone" with label "Address Phone_Patch 1.1.3.0" and then added back the field, this time with label "Address Phone_Patch 1.1.4.0":

Then, I have exported the Patch Solution 1.1.4.0 as managed and imported in my STAGING environment.

As you can see, the field "Address Phone" has been duplicated, because removing and reinserting it into the Form has caused the creation of a new element with a new ID, if you observe the XML equivalent block:

This is the fragment associated to the field as specified by the Patch Solution 1.1.3.0:

This is the fragment associated to the field as specified by the Patch Solution 1.1.4.0:

In order to resolve this extra issue, I decided to try performing a double patching: with the first Patch Solution I wanted to remove the field, and with another Patch Solution I wanted to inserting back the field with a new label. It didn't work neither at first stage, because even though with Patch Solution 1.1.4.0 I had removed the field, this was continuing to appear into the form:

The last tried, that finally worked, has been consolidating all the patches into a Clone Solution. In this way, a major solution release is created, and the finally form design was as expected:

As a final consideration, I would say that if you want only to add new fields into forms, you can adopt the Patching Solution strategy. But if you are planning to perform changes to fields already available into the forms, then the Cloning Solution strategy should be the preferred way.

Regards,

Marco

Reply

SBX - Two Col Forum

SBX - Migrated JS