Managing Solution Files with Power Platform CLI

The Shift to a Code-First Workflow

Manually exporting and importing solution zip files through the maker portal is sufficient for simple projects, but it doesn't scale for professional team development. It lacks version control, repeatability, and automation. The Power Platform CLI bridges this gap by allowing you to script and automate every aspect of solution management.

Let's begin by getting acquainted with the CLI and its core capabilities for solution management.

As you saw, before you can manage solutions, you must establish an authenticated context. The pac auth and pac org command groups are your tools for managing connections. A best practice is to create one authentication profile per credential and then use pac org select to switch between target environments within that tenant.

From Environment to Source Control: Unpacking Solutions

The first and most critical step in adopting a source control strategy is to convert your solution from a binary .zip file into a structured, text-based format that tools like Git can effectively manage. This process is called unpacking.

The Power Platform CLI offers two primary ways to achieve this:

1. pac solution clone: This is a high-level command that combines exporting from an environment and unpacking into a single step. It also creates a .cdsproj file, which essentially turns your solution into a buildable project, something you'll be familiar with from your .NET experience.
2. pac solution export + pac solution unpack: This is a two-step process where you first export a solution to a .zip file and then explicitly unpack it.

So, when should you use each?

To summarize the key distinction:

• Use pac solution clone when you are setting up a project for the first time or when you need to add new components (like a plugin assembly) to your solution project file (.cdsproj).
• Use pac solution export followed by pac solution unpack when you are only modifying existing components within the solution and don't need to update the project structure. In an automated pipeline, you will often see export and unpack used as distinct steps.

Let's see the clone command in action and discuss the resulting file structure.

The Unpacked Solution Structure

After running clone or unpack, you are left with a folder structure that represents your solution on the file system. This is what you will commit to your source control repository.

The resulting directory is highly organized.

As the article explains, you get a root folder containing:

• A .cdsproj file: The project file that references all solution components.
• A .gitignore file: To prevent build artifacts (like the packed .zip file) from being committed to source control.
• An src folder: This contains subfolders for each type of component (Entities, WebResources, PluginAssemblies, etc.), with component definitions stored as XML or their original file formats (e.g., .js for JavaScript).

This structured, text-based representation is ideal for source control, as it allows you to see line-by-line changes, merge work from multiple developers, and track the history of every component.

From Source Control to Environment: Packing and Importing

Once your solution is in source control and you've made your changes, you need to reverse the process: pack the source files back into a deployable .zip file and import it into a target environment.

• pac solution pack: This command reads your unpacked solution folder and creates a solution.zip file. You can specify whether to create a Managed or Unmanaged solution using the --packagetype parameter.
• pac solution import: This command takes a solution.zip file and imports it into your currently selected Dataverse environment.

For a developer, a more common workflow is to simply build the project. Running dotnet build or msbuild on the folder containing the .cdsproj file will automatically restore dependencies and run the pack command for you, producing the solution zip file in the bin/Debug or bin/Release folder.

Let's see how the import command works and explore some of its powerful options.

Ensuring Quality: Checking and Versioning

Before you import, you can programmatically check your solution for issues.

• pac solution check: This command submits your solution .zip to the Power Apps Checker service and reports any violations of best practices related to performance, security, or reliability. Integrating this into a build pipeline is a key DevOps practice.
• pac solution version: This command allows you to programmatically update the solution version number, often by incrementing the build or revision number. This is useful for ensuring each build has a unique version.

These commands are demonstrated in the final part of the video.

Conclusion

In this lesson, you've learned how to use the Power Platform CLI as your primary tool for managing the lifecycle of a solution. This code-first approach is the bedrock of professional Power Platform development and a prerequisite for automation.

Key Takeaways:

• The Power Platform CLI enables you to script and automate solution management tasks.
• pac solution clone or pac solution unpack are used to convert a solution into a source-controllable format. The unpacked structure is organized by component type.
• pac solution pack (or dotnet build) recompiles the source files into a deployable managed or unmanaged .zip file.
• pac solution import and pac solution check are used to programmatically deploy and validate your solution, forming the basis of a CI/CD pipeline.

What's Next?

You now know how to get your solution into a format suitable for source control. The next logical step is to do just that. In our next lesson, we will set up a source control repository (e.g., in Azure DevOps or GitHub) for a Power Platform solution. You'll take the unpacked solution files from this lesson and commit them to a repository, establishing a single source of truth and taking your first step towards building a fully automated build pipeline.