When I’ve heard about the Preview for Power Platform Extension for Visual Studio Code (announcement) , it seemed to me that it was all about using Power Apps CLI (pac) inside Visual Studio Code. But the “pac cli” could be used inside the VSCode Terminal without the extension too. I did that ever since I’m developing PCFs. So what’s the deal with the VSCode Extension? It was time to unpack my detective tools…
What is the Power Apps CLI (pac)
As a PCF developer, we were working with it from the beginning: the Power Apps CLI. It allowed us to create a PCF project and a CDS(Dataverse) project, later it made possible to push a debug version of the PCF to the environment. With the time more features were introduced: it would allow the creation of a PlugIn project, working with Solution Packages.
The rebranding of Power Apps CLI to Power Platform CLI
I’ve actually descovered the rebranding by hazard, as I was trying to understnad the VSCode Extension. The Power Apps CLI was renamed to Power Platform CLI. I didn’t saw it anywhere, not even a post on Twitter about this. Usually there is a big ceremony around rebranding, but this one was quiet. I wonder why? Maybe a lot of developers doesn’t know about the pac cli, or consider it as a PCF-thing? Or maybe because everybody knows it as “the CLI”, and the prefix was not that important ?
The good news is that the name of the command won’t be changed, so we can continue to use “pac”.
Why a VS Code Extension?
Of course one of the reasons for the extension is to meet the developers right where they are, inside VSCode, without leaving the IDE, without having to take care to set the PATH in the Windows Environment Variables, without having to install the MSI Package…
Maybe an important reason is trying to emphasize that the CLI is not a PCF-thing only. It has much more features: like plugin projects, working with the environment and Dataverse solutions, work with portals and canvas apps and even package projects. I love each of them. Have a look at the “pac help” output:
Another enhancement is that the extension is supported not only on Windows10 anymore, but also on MacOS (as shown in the announcement of the VSCode Extrension)
The VS Code Extension is not only about the PAC CLI
Even if we see mainly the pac cli when we read about the VS Code Extension, it actually has more goodies dedicated to the developers. It has icons and snippets. Most of it is made for portals right now, but maybe more will come with the time.
PAC Standalone vs VS Code (MSI vs NuGet)
The standalone “pac cli” can be installed from here as a MSI Package. The VS Code Extension is installed as a NuGet Package. We can have two several versions of “pac” at the same time. For instance, first time I’ve installed the VSCode Extension with version 1.6.7 while the standalone cli was 1.6.6. In the meanwhile both “pac” packages are available in version 1.7.2. But you need to upgrade them separate.
The command options are almost the same:
The difference resides in “use” and “install” commands, which are not available in VSCode. So in VSCode we cannot use the commands to switch the “pac” version or to install a new one. That makes sense, since we can up/downgrade it using the VSCode Extension itself.
To avoid confusions, the “pac cli” version is the one we see in the terminal after we type “pac”, and has nothing to do with the VSCode Extesion version.
Pac auth is used by both MSI and NuGet
Even if the MSI and Nuget “pac” packages are living independent of each other, each of them having it’s own version, they have something in common: the “pac auth”. That means that we need to create the authentication profiles only once and it will be used by both of them. Check them out by using “pac auth list”
I start to like the VSCode Extension, even if for now I don’t have much benefit compared to the MSI Package. In the next post I’ll write about troubleshooting the VSCode Extension. Read it here