pac pcf version strategy

… now I won’t forget to increment the manifest version anymore 🙂

Usually when we develop PCF components, we can use “pac pcf push” to upload the debug version to the app, and don’t have to increment the manifest version. But when we are done with the development, we need to increment the version inside the manifest, just before we use “msbuild” for generation the solution. Usually I forget to increment the version, I start the “msbuild”, which takes pretty long, and then I remember and have to start over again. Yesterday I saw the that there was an update to the “pac cli” (version 1.3.6), which might help. The documentation doesn’t say much, so I played around with the features. The content of the blog is a combination of reading the docs, the release notes, guessing and observing. I have no idea if that’s the intention behind this feature. It could be that I will have to change some parts of the blog, if I get more information. But this might help for now too.

“pac pcf version –strategy”

The first thought was, that I just have to define the strategy, and the manifest will automatically be incremented when I “build” using msbuild. Well, it’s not working that way. This command will just change the manifest version when you call it. The beauty about this feature though, is that you don’t have to know to which patch version you want to update, it automatically decides for you. And you have 3 possible strategies:

• manifest
• filetracking
• gittags

The “manifest” strategy

pac pcf version -s manifest

When you call this command, you have to located in the directory where your “.pcfproj” is placed (the root of your project). This command will find your manifest, and increment the patch version. So the version “version=”0.0.4″ will become “version=”0.0.5″. It relies on the current version in the manifest, and increment that version: nice and easy.

The “filetracking” strategy

pac pcf version -s filetracking

When you call this command for the first time, it will create a file called “ControlsStateVersionInfo.csv” right beside your “.pcfproj”. This file looks something like this

ColorfulOptionsetGrid,B3FB865F44C124B97E38B1351CD54C35BEF2FF7146BA51F5FB8E2C504F3D8262,0.0.1

The first is the name of my pcf control, the “0.0.1” is the pcf version. For each execution with “–strategy fieltracking”, it last part (version) be incremented, and the manifest version will be automatically be updated with this version.

Maybe is important to mention that even the manifest has already a higher version, calling the “pac pcf version” with “filetracking” strategy, will start with version 0.0.1, which will be also be set in your manifest version. So in case the control has already a higher version, you have to change the version manually in the “csv” file , and call the the “pac pcf version -s filetracking” again.

I actually prefer to go with the “-s manifest”, but there might be cases where the filetracking helps in case we have to sync the state of more components. I’m sure there are some more cases, that I am not aware of (until I need it 🙂 ).

The gittags strategy

That’s a little complicated. I found a few things documented.

In the release nodes I could find

PCF ControlManifest versioning can now automatically increment patch version using git tags to store previous versions.

Can push gittags patch versions using PAT

And there is an important information in the “pac cli” itself (help)

If using gittags, set personal access token in the following environment variable “PacCli.PAT”

So the “gittags” strategy uses git tags to monitor the version. It creates tags and updates the manifest version based on this tags.

But since the CLI needs access to the git repository, there is a setup needed.

• First you need a github PAT: “Personal Access Token”. You can set this up as documented here.
• Then you need to set the Environment Variable in your System settings, called “PacCli.PAT” (funny, when reading “Environment Variable” my first thought was Dynamics 365 Solution Environment Variables 😂 )

Now each time you call the “pac cli”, setting the version strategy “gittags”

pac pcf version -s gittags

you will get a new tag created for you, and the manifest will be changed based on the existing tags.

The tags are looking the this:

It worked a few times, but then it got stacked with “0.0.5” version, and every time I execute the command, I get another “0.0.5” tag, and the manifest will be updated again to “0.0.5”.

Not very sure if it’s a bug or I’m missing something. I’m sure it will be really cool; especially in combination with a Release Pipeline, could lead to a clean deployment. But since I don’t use Release Pipelines right now (that’s pretty high on my todo list: prio A ,but not A++ yet 😉) I’ll personally stay with the “manifest” strategy for now. I’m sure there will be clean pipeline implementations with this ; I look forward to see them.

How can I make use of that?

Ok, so the manifest won’t be updated automatically, but I have a way now to increment the version. In order not to forget to update the manifest version again, I’ve created a VSCode tasks file, where all the steps are called:

• increment manifest version
• call msbuild
• call msbuild /p:configuration=Release

To do that, I’ve defined a file named “tasks.json” inside the “.vscode” folder in my root folder (if you don’t have it, you can create it).

So when I want to make a release solution for my PCF, I call in VSCode

“F1” -> “Tasks: Run task” -> and then choose “RELEASE” from the list.

My “tasks.json” is looking like this (below). The only problem is that I have to change the name of the solution folder (in my case “Solution/ColorfulOptionsetGridSol”) if I want to use it for other projects. That’s because the “pac pcf version” has to be executed in the “pcfproj” folder, while the msbuild has to be executed from inside the “Solution” folder (.cdsproj).

{
    "version": "2.0.0",
    "tasks": [
        {         
            "label": "incrementManifest",
            "type": "shell",
            "command": "pac pcf version -s manifest",
            "problemMatcher": []
        },
        {       
            "label": "buildDebug",             
            "type": "shell",            
            "command": "\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\MSBuild\\Current\\Bin\\MSBuild.exe\"",
            "args": [     
                "Solution/ColorfulOptionsetGridSol"               
            ],
            "problemMatcher": [ "$msCompile"],
            "dependsOn": [
                "incrementManifest"
            ]
           
        },
        {
            "label": "buildProduction",         
            "type": "shell",            
            "command": "\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\MSBuild\\Current\\Bin\\MSBuild.exe\"",
            "args": [                
                "Solution/ColorfulOptionsetGridSol", 
                "-p:configuration=Release"
            ],
            "problemMatcher": "$msCompile",
            "dependsOn": [
                "buildDebug"
            ]
        },
        {           
            "label": "RELEASE",
            "dependsOn": [
                "buildProduction"
            ],          
            "problemMatcher": []
        }
    ]
}

I preferred to let steps be executed sequential, since I had the feeling that it doesn’t execute well if the buildDebug is executed parallel with buildProduction.