Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
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?
Check this stackoverflow.com/.../display-text-label-not-updating
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.
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
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 220.127.116.11:
Based on the same Base Solution in DEV, I've prepared the Patch Solution 18.104.22.168, where I have removed the field "Address Phone" with label "Address Phone_Patch 22.214.171.124" and then added back the field, this time with label "Address Phone_Patch 126.96.36.199":
Then, I have exported the Patch Solution 188.8.131.52 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 184.108.40.206:
This is the fragment associated to the field as specified by the Patch Solution 220.127.116.11:
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 18.104.22.168 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.
Business Applications communities