The Most Important XML Files in a Solution

How the export itself is created is covered in exporting a solution. If you unpack a solution export, you do not find a lucky bag but a small, stable order. Once you know it, you find the answer to most questions without access to the environment. Here are the files one by one, in the order in which it makes sense to open them.

solution.xml: the manifest

The smallest file first. It holds the unique name of the solution, the version, the publisher with its prefix and the field "Managed", which tells you whether the export is managed or unmanaged.

This is what the core of the file looks like, schematically:

<ImportExportXml>
  <SolutionManifest>
    <UniqueName>KundenportalKern</UniqueName>
    <Version>1.4.0.2</Version>
    <Managed>0</Managed>
    <Publisher>
      <UniqueName>fabrikam</UniqueName>
      <CustomizationPrefix>fab</CustomizationPrefix>
    </Publisher>
    <RootComponents>
      <RootComponent type="1" schemaName="fab_projekt" behavior="0" />
      <RootComponent type="29" id="{3f2504e0-...}" />
    </RootComponents>
    <MissingDependencies> ... </MissingDependencies>
  </SolutionManifest>
</ImportExportXml>

Two lists are more interesting than the metadata. "RootComponents" lists which components the solution contains at all, with type numbers instead of plain text. And "MissingDependencies" lists what the target environment has to bring so that the import succeeds. Each entry names the solution that the required component comes from. If you read only a single file before an import, read this one.

customizations.xml: the substance

The big file. Tables with fields, forms, views and relationships, plus classic workflows, business rules, security roles, option sets and app definitions. What is in there and how to read it, I described in a separate article. For the overview, this is enough: almost every question about the content of the configuration ends in this file.

Content_Types: the inconspicuous mandatory file

The file "[Content_Types].xml" only describes which file extensions occur in the package. It belongs to every export because the package follows the Open Packaging format. It contains nothing analytical. It is worth mentioning for one reason only: if you repack an export by hand and forget it or damage it, the import gives you an unhelpful error message.

The component folders

Not everything fits into the customizations.xml. Some component types sit in the package as folders of their own, each with its own formats:

• WebResources: the JavaScript, HTML and image files themselves, under cryptic file names. The mapping is in the customizations.xml.
• Workflows: the actual definitions of the processes. Power Automate flows are stored here as JSON, with trigger, actions and connections in plain text. That makes this folder valuable for any review. Classic workflows, business rules and business process flows sit in the same folder as ".xaml" files. In the customizations.xml, each of these processes only has an entry with name, type and a reference to the file.
• CanvasApps: canvas apps as msapp packages of their own, which are archives themselves.
• Depending on the content, more folders, for example for environment variables, custom APIs, connection references or AI plug-ins. In recent years the platform has moved more and more types out of the central file into such folders.

A practical reading path

For a first assessment of a foreign solution, this order has proven itself. First the solution.xml for scope and dependencies. Then a look at the folder list to see which technologies are in play at all. Then targeted into the customizations.xml for the questions that follow from that.

If you start with the big file instead, it is easy to get lost. The small files answer the classification questions faster.