Removing your Command Bar Unmanaged Active Layer in Model Driven Apps

Removing your Command Bar Unmanaged Active Layer in Model Driven Apps

In the last few months I have been working on upgrading the customer´s unmanaged environments to managed. The customer had been working with unmanaged environments for about 5 years, and after joining, this has been one of the first things that I determined would be needed for this customer.

The challenge was not so easy. We are still not fully managed in all the environments, but as a stepping stone, all environments with the exception of production are already managed and as we are working on a large migration, the final deployment is only a few months away.

After reading and watching the Microsoft blog and video on what they had to go through with Success Hub, I felt that my endeavor was not as complex. You can read the blog and see the video by clicking on the links below:

https://powerapps.microsoft.com/en-us/blog/how-a-microsoft-team-transitioned-from-unmanaged-to-managed-power-platform-solutions/

https://docs.microsoft.com/en-us/power-platform/alm/move-from-unmanaged-managed-alm

https://www.youtube.com/watch?v=3Uu5C9zkIjo (PowerCAT Live)

As with many of these special projects, there are sometimes blockers that you need to address with the functionality of your application. Ours was related to command bar customizations not being deployed from our development environment (unmanaged) to our QA environment (managed).
My apologies in advance for all the bluring, but this was the only way to get the screenshots.

The screenshots below show the difference between the functionality in our development and qa environments after the re-deployment of our managed solution to qa.

Command Bar UX - Dev Environment

Command Bar UX - Test Environment

As we saw this difference we wanted to go ahead and compare the Ribbon customization differences between the environments, and just as the UX had the differences, so did the commands themselves. It seemed like there was an enable rule missing in the qa environment that was not missing in the development environment. This was done of course using the Command Checker utility that can be invoked by adding the ribbondebug=true key/value to your query string
(ex: https://dev.crm.dynamics.com/main.aspx?appid=1234&forceUCI=1&ribbondebug=true&pagetype=entityrecord&etn=account&id=1234)

See image below for comparison

Command Bar Check - Dev Environment

Command Bar Checker - Test Environment

As with many of the know issues with managed solutions and customizations that do not get overwritten (we experienced this with cloud flows as well), the issue is usually when there is an Unmanaged Layer on top of a Managed layer, and then the customizations do not get overwritten.

When we clicked on the Command Checker, and selected the command that was not performing as expected (1), chose Command Properties (2) we can see the rules that were supposed to be enabled in this environment.

Command Bar Checker - Get to solution layers

The rule that we were expected was not visible. Clicking on the View command definitions solution layers (3) will display any layers that are being used for the command that we are looking at. The image below shows you the results that we saw when clicking on the link.

Command Bar Checker - Layers

In the Command checker solution layers pane, you can also select two layers and compare them to see the CommandDefinition code of the RibbonDiffXml.

Once we saw that there was an Unmanaged Layer (Active Layer) on top of our managed solution layer, the solution was pretty easy, but we required to do this in a few places.

The first thing is we created a new solution in our qa environment. We called this solution Command Bar Fixes, and added the table were we had to fix the customizations. When we added the table, we only selected Include table metadata from the options, and did not select any components. Image below:

Command Bar - Add Table to Solution (Table Metadata Only)

Our solution contained a single table with only the table metadata as shown below.

Command Bar - Export Table Metadata Solution

We then Export the solution. There should not really be a need to publish customizations before (as we have previously seen the results in the Command Checker), but if you are accustomed to this practice, do not change your ways…

Once we export the solution, we navigate to our downloads folder and extract the Command Bar Fixes solution. We open the newly created folder, and within the folder we open the customizations.xml file using an editor of our choice. The customizations.xml file should contain the table specific information as well as the Ribbon Diff Xml and other information about the table. The image below shows this file before we fix it.

Command Bar - Import Export Xml (Before Changes)

I collapsed the RibbonDiffXml containing all the commands, as these are not really relevant. We will go ahead and remove all of the inner Xml of the RibbonDiffXml section, and only leave the <RibbonDiffXml /> tag so that it looks like the image below.

Command Bar - Import Export Xml (After RibbonDiffXml removal)

We then save the changes, and select all the files that are in the extracted folder. Right click and select Send To, and Compressed Folder. We will reimport the newly created zip file.

Navigate back to the Maker portal, click on solutions and select import. In the browse panel, select the zip file that you just created containing the customizations.xml, solutions.xml and [Content_Types].xml.

Import the file and publish your changes. After this navigate back to the table were you experienced the issue and validate that the active layer is now gone and you only have the managed layer.

Hope this was helpful. It was painful for us to get the resolution, so maybe it will help some of you.