Use XML map files to keep Power Platform ALM binaries pipeline-built
Diesen Beitrag auf Deutsch lesen
Explains how XML map files connect solution Plugin DLLs and Webresources to locally built binaries during PAC CLI and Power Platform Build Tools pack, unpack or clone operations.
TL;DR
XML map files define where solution Plugin DLLs and Webresources are stored locally, allowing the platform to suppress binaries while pipelines build them on demand. The post shows folder, file-to-file and file-to-path mappings, then configures a DemoPlugin.dll mapping and supplies a MapFile path for an Azure DevOps unpack or pack step.
Original by Benedikt, on Benedikt's Power Platform Blog. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Admins/CoE: set up one map file per solution and reference it in every PAC CLI or Build Tools pack and unpack step, so downstream exports always contain pipeline-built binaries instead of whatever a developer’s machine last produced.
- Makers: building plugins or web resources should keep the compiled DLLs and JavaScript out of source control entirely and rely on the mapped local path — checking in a binary the pipeline is meant to generate defeats the whole point of the mapping.
Frequently asked questions
What does an XML map file do in Power Platform ALM?
It defines which plugin DLLs and web resources belong to a solution and where they are saved on the local disk. The pipeline can then use freshly built binaries from the build output.
Which mapping types can a Power Platform map file use?
Folder mapping maps a whole folder and is typically used for web resources. File-to-file mapping links one source file to one target file and is common for plugin DLLs.
Why are map files needed when solutions already contain the components?
Depending on whether you follow an environment-centric or a source-code-centric ALM approach, a solution may be created from an environment instead of a repository.