I’ve been always wondering if editing a customizations file should be considered an “unsupported” customizations. That was sort of my gut feeling since, after all, that file is rather complex, and it’s not something you can edit easily – you have to go over a few steps to even get that file, and, then, you have to go over a few more steps to put it back to Dynamics:
- Create a solution
- Add all the necessary components to that solution
- Export the solution
- Unzip the file
- Find “customizations.xml” file in the folder
- Modify XML in that file
- Then package everything into a new zip file
- And import that file into Dynamics
That’s quite a few steps not to mention that the file itself looks rather complex if you’ve never seen it before. For example, there are over 11000 lines in the customizations.xml for the TCS Tools solution:
So, manually updating that file must be unsupported, right? After all, we are supposed to configure Dynamics using the “customizations” interface. That’s what I used to be thinking (but that’s not to say that I would never update customizations.xml manually, though. Even if I felt somewhat guilty every time I’d be doing that). And that’s until I ran into this article just a few days ago:
When to edit the customizations file
As it turned out, it’s not just supported.. There is a bunch of tasks that you may want to do directly in the customizations.xml. Some of them can be done through the user interface, some of them can be done using the SDK. But, if you wish to, you can make those changes directly in the customizations.xml:
- Editing the ribbon
- Editing the SiteMap
- Editing FormXml
- Editing saved queries
Actually, if you look at those 4 items, it kind of makes sense.
There are no SDK methods which you can use to update the Ribbon, yet you cannot do much about the Ribbon in the user interface. Of course there is Ribbon Workbench, but what it’s actually doing exactly that – it’s updating customizations.xml.
There are no SDK methods which would allow us to update FormXml either. More exactly, we can use SDK to update form records.. but we still have to use XML there. Or, alternatively, we can update customizations.xml, package the solution, and import it to Dynamics.
As for the save queries, that’s, probably, even more interesting. When building those queries in the user interface, we have to accept some limitations such as:
- Can’t use distinct=false
- Can’t use left-outer joins
- Can’t link the same entity more than one
- Etc
However, since FetchXml has support for all those feature (and it’s only a user-interface limitation that we can’t use them), we can still update those queries directly in the customizations.xml and import those changes to Dynamics.
This is not necessarily a game-changer, but it definitely makes me feel better keeping in mind that there is, probably, not a single Dynamics implementation where I would not make at least one of those changes in the customizations.xml (even if only to add a ribbon button using Ribbon Workbench)
I have tried updating a saved query for a view in the customization.xml to link multiple entities by following the steps in http://dynamicscrmcoe.com/creating-complex-views-in-dynamics-crm-2015/. But when I imported the solution back, I am getting the message ‘This field has been deleted. To use or save this saved view, you must remove the field’ on the new field. Please could you advise how to resolve this?
How do you locate the ‘Managed Property Name: iscomponentdeletionenabled; Component Name: Attribute; ‘ in a customizations.xml file? Do you have to build the solution including the Metadata? I want to delete a custom field we created that became managed when someone overwrote the database with a Production copy where the solution was managed and no backup was saved.
Off the top of my head I’m really not sure. Try asking in the community forum (not the answer you want, but the best I can offer right now). This situation with prod brought over to dev is exactly the reason I am always cautious of the managed solutions.
Assuming you are on-prem (databases?), you might try this:
https://community.dynamics.com/ax/b/thedynamicsblog/archive/2014/07/14/converting-managed-solutions-to-unmanaged-solutions-crm-2013
I like how you casually say “Add all the necessary components to that solution”.
A fully developed customized app can have many many customized components and entities. the only way to add them all to a new solution is to do it manually(IF you actually know what they all are)