Firstly, we have a new icon for the Power Platform CLI and the Power Platform Developers tools in general, and it looks like this.

A lot of you folks had asked for something more meaningful to represent the developer tooling capabilities of power platform. Well, we finally delivered, and we are happy for it. Thank you all for your support. You will start seeing the icon updates happen shortly in all the relevant web tooling properties like the Visual Studio Code activity panel, Azure DevOps, Visual Studio Marketplace etc. just to name a few.

Less noisy solution.xml

Now let us get into the meat of things. We did not put a blog out in January, but one of the features that we included, and we did not talk about was that solution.xml is less noisy when diffing in source control repositories. Here is an example of the same solution files unpacked with an older version versus the new version of Power platform CLI. The new output is on the left-hand side of the picture below

New command!! (Preview) The fetch command

We knew a lot of folks in the community used the fetchxml capability to query dataverse, and our team’s internal build had a similar command that is used by our development team everyday. We have decided to make this command available in preview capacity for you all to use in the innerloop context. For those you who may not be aware of the fetch capability. Developers building applications for Power Platform usually need to query the dataverse instance to get various properties of the Dataverse entities in question. We now have the ability to do the same thing in the Power Platform CLI. When using the -x parameter remember to have all the XML nodes in a single line and not multiple lines or you can use the -xf and read it from the XML file

New Command !! pac admin status

When using the Admin commands, which operate in async mode, most of you had asked us, ” how do I really know if the async job request is done?”. Now we have a command that shows you the status of the async job with pac admin status

More details of the all the features are captured in the release notes at this link

Please try out these capabilities and give us feedback at the following location ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode.

The post Releasing the February Update for the Developer Tools (Power Platform CLI) appeared first on Microsoft Power Platform Blog.

Support for Managed Identities in Azure DevOps

This has by far been one of the most requested features. Support for Managed Identities in Azure DevOps. The Managed Identities support has to do with Azure DevOps pipelines, self-hosted agent pools. So before you get started in Azure DevOps, you need to go to Azure Portal and Create an Azure VM Scale Set

Figure 1: Script to create a VM agent pool

Assign a system managed or a user managed identity to the VM Agent pool. Notice the Object id, as this is needed later.

Figure 2: Created a system managed Identity for the VM Agent Pool

Now Let us go into Azure DevOps and go to <DevOps Organization -> settings -> Agent Pool and create a new agent pool mapped to Azure VM scale set

Figure 3: Assigning an Agent Pool in Azure DevOps

Add a new agent pool and map this pool to your VM scale set and give it a useful name.

For the maximum number of virtual machines option select 5 (keeping it small) and the number of agents on standby as 2 and proceed to create.

This will now create a new agent pool for you to use in your Azure DevOps pipeline.

Now once this is done, there is one more thing you need to do, create the service connection to use the managed identity for authentication.

Figure 4: Creating a managed identity service connection

Now we create the service connection to use the Managed identity.

For the URL parameter, provide the URL for the environment in question.

And then go to azure and make sure that the Appid for the managed environment has access to import solutions in the dev environment.

Remember the object id for the system managed identity this is where it is useful. You need to get the application ID for Power Platform.

Figure 5: Getting the Application ID for the Managed Identity

Now, add it to the environment as shown in this figure and give the app id the right role here in this case I have given it the System administrator role.

Figure 6: Adding the Managed Identity App id to the environment

Change your agent pool to the one you have created and make sure to install .NET core 6.x if you are using Linux agents in your VM pool when running the pipeline.

And the service connection in this case we have changed the service connection for the pipeline and executed the pipeline. Now you can successfully run an Azure DevOps Pipeline with Managed Identity. The wonderful thing about this feature is that when the VM scale group is removed the App identity does not have access to your resource. The best part about managed identities is that you do not have to worry about secrets and key rollover, those are just done as the secrets are managed by Azure and the organization policy you have set in place.

Note: Managed identities are not supported for GitHub actions, yet. If you need us to support the capability in GitHub actions, please let us know.

Assign groups to environments

No sooner than we added the ability to assign-user, we were asked to have the ability to assign an application user and when delivered on that, you asked us to provide the ability to assign user groups. In this update you can now assign groups to newly created environments. This is available in the command line, GitHub Actions and Azure DevOps.

Support for Power Platform Pipelines

We just recently announced the availability of Power Platform Pipelines, and now using the Power Platform CLI you can list and execute pipelines that are created in Power Platform Pipelines. The new verbs for this new noun are list for listing pipelines and deploy for deploying pipelines.

Virtual Agents

This noun was behind the feature flag for a long time, now it is finally here. We only have one verb for support and that is list. It will list out all the virtual agents in your environment.

As you can see, we have continued with our monthly cadence and we always hope to delight our users. Because we are heading into the holiday season, the December/January update will likely ship in February next year. Please try out these capabilities and give us feedback at the following location ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode.

Happy Holidays and Wish you all a Great New Year!

The post Power Platform Developer Tools November update appeared first on Microsoft Power Platform Blog.

Username and password versus Service Principal

When using Azure DevOps, the Power Platform Build Tools provides you options to either create service connections i.e., username and password or Service Principal (SPN). We recommend that you use Service Principal instead of username and password. There is nothing wrong with username and password, it is just that when you have Multi-Factor Authentication enabled, it will break your pipelines. You can use a generic service account as well, but just make sure not to enable MFA for that service account.

Figure 1: Service Connection with Username and Password

Figure 2: Service connection with Service Principal accounts

To create a service principal registration, please use the steps listed in the following location: https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools#configure-service-connections-using-a-service-principal

When using service principals, it is important to understand that service principal used to run your pipeline can and should be different from the service principal authentication you use to your backend data source in the application you are deploying. They should be different SPN’s as a best security practice.

Power Platform tools installer

When creating your pipelines your first task is to install the Power Platform Tools installer. The purpose of the task is to install the latest version of the Power Platform tools to run your builds

Figure 3: Power Platform Tools installer

Set Service connections

Service connections contain the credentials to use for the backing APIs.  In scenarios were the pipelines need to perform tasks that we do not offer in the Build Tools; we often see users adding Powershell or direct API calls in their pipelines. Set Connection Variables allow the credentials inside the Service Connection to be shared securely for use with Powershell and any other cli that needs those credentials to get a token for the same identity in the service connection.

Administrative tasks

Creating ephemeral test environments and assign user

The Build Tools includes the ability to create and delete environments. This enables you to create a test environment on the fly, load the application to be tested, test the application and then delete the environment as part of the CI/CD process. Although the Application testing part in this case is manual today, in the future, we expect to fully integrate the Test Engine effort into the Power Platform Build Tools in the near future.

Some users use other community-based testing tools to accomplish such capability as well.

You can also use your Azure Pipelines to backup, restore and copy environments.

When using a SPN to create such environments, note that the SPN becomes the owner of these created environments. If you want to change the ownership of these environments to be an interactive user or another SPN, we have introduced a new task called assign user.

Figure 4: Assign user task

Username can be an application id or a user object id and the Role has to be a role in Dataverse for the newly created environment.

We encourage you to explore some of the other administrative tasks available to Power Platform Build Tools for Azure DevOps.

solution tasks

Most of the tasks available are focused on solutions, since solutions are what you use for any Application Lifecycle Management (ALM) objectives on the Power Platform. When you want to move applications from Development to Test to Production, you should always ensure that all your applications, cloud flows, and bots are in a solution. The following solution tasks are available in the Power Platform Build Tools for Azure DevOps:

Figure 5: Solution tasks in Azure DevOps

Set solution version

Once you have successfully imported a solution to the target environment you can set the version on the imported solution. This is generally useful if, users want the solution version to mimic what is captured in the Git repository tag or if you want to keep the version numbers consistent across environments, especially when going from Test to Production. The version number is generally a 4 number tuple

Figure 6: Setting a solution version

Solution pack and unpack

When you are exporting a solution from the Power Platform environment, and before checking in the solution zip file into the Source Code repository you should always unpack the solution.zip to have the solution represented and understood by your source control system. Use the unpack command to extract the content and check it in to the repository. Consequently, when exporting a solution that is unpacked in a source code repository, you must pack the relevant artifacts back into a solution.zip in order to be able to import it and hence you have the pack command available for this.

Export solution

This task is self-explanatory. When you want to export the artifact from a source environment and put it into a Source code repository, you need to export the solution and this task is created to support such that.

Import solution and apply solution upgrade

Just solution export, solution import works in the inverse. But one of the interesting steps in importing a solution is especially when upgrades are in place. Remember, when applying upgrades, it removes unreferenced resources, you can import the solution as a holding solution.

Figure 7: Apply solution upgrade

Once the solution is imported as a holding solution then you can run the Apply Solution Upgrade task to complete the import and application of the new changes you are committing to the environment.

Add solution component

When importing a solution if there are other required components that need to be added, then you can list those specific components out. Hence when importing, all those listed components will be added. This will increase the size of the solution as a lot of the dependents will be pulled in. This is the same capability in the Maker UI, where you can add required objects.

Figure 8: Adding the solution component

How does one find out the component and the component type? When you unpack a solution and open up the solution.xml in the Other directory. In the solution.xml file there is a list of all the components and their respective component type.

Figure 9: Component and their component type

Publish Customizations

Although this is a top-level task it is to publish customizations for all the solutions in the environment. You can specify the environment URL or use the environment set in the variable and it will then publish all the customizations.

Figure 10: Publishing customizations

Deploy package task

When you have an application that spans multiple solutions, you can add them to a package. When such a package exists, you can deploy the package using this task. You can also specify the runtime sequencing of the applications.

Figure 10: Package deployment task

Conclusion

These are just a few of the details on how these tasks are used in the day-to-day function of Power platform in the context of a CI/CD environment in Azure DevOps. If you have additional feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://github.com/microsoft/powerplatform-build-tools

The post Power Platform build tools and Azure DevOps appeared first on Microsoft Power Platform Blog.

Power platform Command line updates

Model builder

We are bringing the ability to generate C# classes for Dataverse APIs and Tables directly from Power Platform CLI. For new developers who want to build applications with Dataverse tables you can now do that. For existing Power Platform Developers, this is the same capability that was provided by the CRMSvcUtil tool. The benefit of using the class generation capability on PAC CLI, is that these classes are .net core compliant.

Figure 1: Model builder generating classes

auth with secrets

When we released the capability to create auth profiles with secret, some users noticed that when a secret started with ‘-‘ or hyphen, the auth profile failed to create. This issue has been resolved with this update so please do try it out!

solution pack ,unpack and sync fixes

The pack and unpack commands now support PowerFx formulas in .yaml for Tables.

In addition, we continue to minimize “noisy diff” issues when committing Power Platform artifacts to source code. To that effect, we are now sorting RootComponents, MissingDependecies, and AppModules in the customization.xml files. This ensures that subsequent exports or `pac solution sync` command execution only adds the changed component line entry and does not cause a diff issue with every line.

Figure 2: Example of sorting in the Solution.xml with this release

Azure DevOps and GitHub Actions updates

Application Install

A few months ago, we released the ability to install D365 and ISV applications environments from the command line. This was done to make it much simpler to prepare developers and test environments with required applications. With this release, we have now enabled the same for our GitHub Actions and Azure DevOps extension so you can easily include these installs in your CI/CD pipeline. One thing to remember when running the task, you need to have the application list provided as input. You can generate that application list using `pac application list –output applicationlist.json`. Once the JSON file is generated, you can edit it to only include the applications you want to install, reorder the list of applications, and provide it as an input into the CI/CD pipeline.

Figure 3: Application Install list json file

Figure 4: Application Install task

provide run-time settings for package deploy

When deploying packages, users using the command line could sequence how the solutions ran during runtime with the `pac package deploy –settings <Key=Value|Key=Value>`. Now this is possible with the CI/CD tasks.

Figure 5: Provide Runtime settings for packages being deployed

If you have additional feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode

The post Power Platform Developers tool – October update   appeared first on Microsoft Power Platform Blog.

NEW: Integrating PRT, CMT, PD into the Power Platform CLI

This is for those of you who are active users of the WPF applications that we have for Plug-in Registration Tool (PRT), Configuration Management tool (CMT), and Package Deployer (PD). On the PAC CLI in Windows, these options are now available under a new noun called “Tool”.

We still have the old way to download from Nuget via a PowerShell Script but we thought we could do better and have now provided the capability to launch these tools from the Power Platform CLI

As developer, you can now do a “pac tool list” and see if the tools are installed

And if you do a “pac tool PRT” and it will go to Nuget the first time and download the tools and launch it

If there is a new version of PRT available, you can now do an update as well and remove the installation from the workstation as well.

Once again, this is only available on Windows as these WPF applications. But we would love to get your feedback. I personally would like to know if you like “pac package deploy” or the package deployer WPF experience @ ISVFeedback@microsoft.com ?

Other updates in the September Refresh

solution export with “_managed” added to the name

As of this release, when you export a managed solution, it will add _managed if the path parameter is not fully qualified. This is true for Azure DevOps and GitHub actions as well.

Package deploy defaults to async for solution import

Starting from this build onwards, when doing a package deploy function, it preselects async for solution import, hence for larger solutions that are being imported, it wont error out and yet still show a successful deployment

Admin commands update

The maximum asynch wait time which was hardcoded to 60 minutes for admin commands is no longer there. This brings in more flexibility, especially when there are operations to restore an environment, which may take longer than 60 minutes.

We are really excited in enabling these new experiences, we hope you enjoy them too. If you have any feedback, please reach out to us at ISVFeedback@microsoft.com or in the Powerusers Community

The post Power Platform Developer Tools monthly release (September Refresh) appeared first on Microsoft Power Platform Blog.

New!! Preview: Pac Connector command

Now introducing the new connector command in the Power Platform CLI. This Power Platform version works against Dataverse. You will now be able to create custom connectors as a code first component directly into Dataverse. If you have custom connectors already created and the pac connector list command does not show it in its output, it is because the custom connector is not in Dataverse. To put it Dataverse, you need just add the connector to a solution.

New!! Certificate AUTH support for Service Principal

From this release onwards you can use certificate-based authentication for Service Principal accounts. This was a widely asked feature from our DevOps users. This is now available.

New!! Assign-user operation can now assign an application ID

When we released the assign user capability last month, we got your feedback loud and clear. Some of you have scenarios where the environment is not owned by a user but by another service principal who is different from the service principal account that is running a pipeline. This kind of a situation occurs when the environment in production is not to be owned by a single user account but by a service principal. I am glad to report that from this release onwards, including in Azure DevOps and GitHub actions, the assign user can now accept an application user (service principal)

New!! Data import capability in Power Platform CLI

For a long time, our users have been asking to get the Data migration tool into the Power Platform CLI. Now you can use the data import capability instead of the data migration tool. Just as move solutions across environments, the corresponding data for such solutions that use their data from Dataverse, we can now move them too. We have introduced the option to export and import and the data can be in a zip file or in a directiory

Moving towards JUST –ENVIRONMENT no more URL or Envid, provide the one that suits with a single parameter

In most of the commands recently you would have noticed that we are removing references to –url or –environmentid to just –environment. So, whether you pass the url or the id, the command will resolve itself from the information provided on whether the parameter passed is a url or an id.

Keeping with that model, we have updated the pac application list and install commands with this capability now

And other commands like solution list and connector list and many more are following a similar path. Going forward all you need to do is provide the –env flag and pass either the url of the environment or the id of the environment and the system will figure out the right one for you.

Just added… the ability to provide runtime settings for packages

During package deployment, although the API allows you to submit runtime settings for the package, such which solution to run first etc. We had unfortunately not exposed that, now we can do that with this release, thereby making a lot of folks who deploy power platform packages happy.

And in addition, for plugin developers, you can now opt-in for strong name signing for your plugin library.

As you can see, we have introduced a number of new capabilities in this update. As always we are looking forward to your feedback on these new capabilities. The forums are the same for feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode

The post Power Platform Developer Tools monthly release update (August Refresh) appeared first on Microsoft Power Platform Blog.

• Power Platform Build Tools: Now based on Power Platform CLI
• New CLI command to assign user
• New CLI command to automatically generate an App from an API definition
• New CLI command to sync existing solution from an environment

Read on for more details and other new capabilities.

Power Platform Build Tools v2.0

Our new version of the Power Platform Build Tools is built on top of the Power Platform CLI, whereas the previous version was based on PowerShell. By aligning these tasks to be based on Power Platform CLI, we can now maintain the same delivery rate of new features as we do with GitHub actions and based on several internal tests with customers these tasks run at 20% to 25% faster than the older version.

We had several internal teams try out and use these pipelines. The ALM Accelerator for Power Platform, built by our Power CAT team, was an early adopter of this “re-platforming” effort.

As most of us know, the ALM Accelerator is a Power App, that has flows, Connection References, and exercises many of the components of the Power Platform. It’s also used to automate the ALM of the tools the Power CAT team build like the CoE Starter Kit and the Creator Kit.  The Power CAT team has a complex setup, with multiple environments, and pipelines comprised of 40+ yaml files. Each pipeline contains up to 30 tasks and even in this complex setup, we saw a significant impact on the pipeline performance with the new version of the Build Tools. The next monthly release of the ALM Accelerator will be upgraded to the v2.0 tasks, so all customers using the ALM Accelerator who upgrade to the next release will benefit from this.

Figure 1: ALM Accelerator setup for deployment using Power Platform Build Tools v2.0

How do you know which version of the task you are using?

When creating your pipeline using the pipeline edit make sure to have the following selections in place to use PAC CLI version. Below is an example from my developer instance:

Figure 2: Task version selection in Azure DevOps between Power Platform CLI version versus the PowerShell version

Once you select a version of the Power Platform Build Tools tasks you cannot mix and match, as the pipeline will not run, as in you cannot have the installer be a different version and the solution import use the PowerShell version.

If you do not want to use the Azure DevOps task editor to change the version, you can use the YAML editor in Azure DevOps and change the version number from 0 to 2

Figure 3: Find and replace the version of the task to be used

To learn how to edit the yaml files in Azure DevOps, please follow the instructions here.

When using Power Platform Build Tools version 2, you will notice that it is also cross platform and can run on both windows and Linux runners in Azure DevOps.

Package Deploy task will not work Linux agents and will require windows runners

New capabilities in the July Refresh for the Power Platform CLI

We are happy to announce an abundance of new features with the July refresh of the Power platform CLI. From cross-platform support perspective, the Power Platform CLI now runs on .NET 6 and uses the generally available version of the Dataverse Service Client (1.0.9). That is just what is under the hood of the command line, but there is more …

Changes in the Admin sub command of Power Platform CLI

We have introduced a new sub command for pac admin, and it is:

• Assign-user

The assign user capability is one of the most requested features, in the past when an environment was created via a pipeline or via the command line from a service principal account then the newly created environment would be owned by the service principal account. Now you can assign a user to the target environment, so that when solutions that have flows that a particular user owns need to be active, well now that is possible, they will be. The sequence of events would be as follows:

Figure 4: Sequence of events in Azure DevOps for assigning user

The command line equivalent looks like this

Figure 5: pac cli command line for assign user

Changes in the auth create command

In the last update we started down the path of single sign-on by providing something called the universal auth profile. You can still create admin and dataverse profiles, but those are deprecated now. With the universal auth profile, if your account has admin functions, you can create environments and run other administrative functions in addition to creating solutions etc. In the July update, we have now introduced creating a universal profile against a selected environment by providing –environment, we did this because when you created the universal single sign-on profile, it would create access to your default environment, now with the –environment flag you can change it.

Figure 6: when creating universal auth profile it defaults to the default environment

Figure 7: creating a universal profile against the selected environment

pac auth update

The new pac update command now provides the ability to change properties of your authentication profiles. Before you could create an auth profile and select different auth profiles. Now you can rename existing auth profiles including the environment to which the auth profile is associated with.

Figure 8: Update authentication property

New Command: pac canvas create

This is a new command developed from the Power Apps team and contributed to the Power Platform CLI. This new capability allows you to generate an App from an API definition. Pro developers who build Azure Functions or other web APIs can create a custom connector that points to the API, and then use the canvas create command to generate a functional app. The generated app can be used to interact with or validate the API. In fusion teams, a pro developer can run the command to generate the app and then hand it off to a low-code maker to make further customizations in Studio.

The generated app will feature a screen for GET and POST actions defined in the custom connector, control layout that is tailored to the input and output types defined in the actions, and auto-generated Power Fx code for interacting with the custom connector.

Figure 9: pac canvas create command

Updates in the org commands

Within the pac org commands we now support selecting a particular org and then support filtering with the list command.

Figure 11: The usual pac org list command

And now with the filter command

And instead of doing and pac auth update, you can now just do a pac org select and change the environment url for the current authentication profile

Figure 12: changing the org for the current auth profile

Updates in the solution command

pac solution sync (preview)

this new command (in-preview) is a handy one, especially if you use pac solution clone like me, has it ever happened that you had cloned a solution from your developer environment, and were working on a PowerFx regular expression and only to realize another team mate of yours changed a different screen in the maker studio while you were editing a regular expression, in the past you had to re-clone your solution and then make sure to reintroduce your changes. Now with pac solution sync you don’t have to do that anymore with sync you just get the delta, and you can continue building your own PowerFx regular expression.

We have also increased the timeout period to 1 hour for pac solution check, the user community demanded this, and we were incredibly happy to oblige.

You can also add a solution component to an unmanaged solution on disk with the command pac solution add-solution-component

Updates for packages and plugin development

The package command now supports the ability to add F&O packages for deployment with the parameter add-external-package
pac plugin push now provides the ability to push updates to an already registered plugin.

Updated Power Platform CLI documentation

Documentation for Power Platform CLI has also been updated with these new commands and parameters that are being offered. Please check out the new reference page and provide us with feedback.

Power Platform Conference in Orlando

One last thing, we have the first ever in-person user conference happening in September for Power Platform

Please register and if you are coming, we have several sessions happening for Code-first developers. Some sessions of interest are:

• Fusion Developer in a Day
• ALM for Citizen Developers and Code First Developers
• Azure and Power Platform Better Together
• Compliment your Low Code/Now Code with Pro Developer skills

Looking forward to seeing you there.

So, even though we did not release the June refresh, we tried our best to make sure that we made up for it in July. As always, we are excited to bring these capabilities to you. If you have additional feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode

The post New version of Power Platform Build Tools and a Feature packed update of Power Platform CLI appeared first on Microsoft Power Platform Blog.

Single Sign-on (Early Capability)

In this new update, when you don’t provide a URL, it creates a universal single sign on authentication profile and authenticates you to your default organization. This is an early single sign-on capability, we plan to improve on it further in the upcoming updates. So, when you use the `pac auth create` command and not provide anything else or `pac auth create -dc` without additional parameters, it will create a new authentication type called universal.

You can still authenticate to other dataverse environments, using the –url parameter. But we would really like to get your feedback on this new single sign-on capability. Please let us know what you think.

Support for China Sovereign Cloud

From PAC CLI we have added support for Azure China Sovereign cloud, this was a long ask from our China based customers and now we can use Power Platform command line capabilities to the China cloud as well. This also means GitHub actions are also supported in the China Sovereign cloud region and eventually we will also support Azure DevOps actions. Here is an example of how you if the China Cloud is supported

Support for Packages that hold .cab files

We introduced a bunch of new changes to the `pac package` command in the last update, As in now packages can also be build just like a solution, except in packages I can bundle multiple solutions and deploy. Now can you deploy packages that *.cab files

Showing if solutions are managed or not on the command line

One of the most frequently asked features by our user community by far. We now have the ability at the command line to know if a solution is managed or unmanaged. In the past the only way a user would know if a solution was managed or unmanaged was when they did an export and the export error out saying the solution was managed. Now when you do a `pac solution list`, you get a column identifying whether the solution is managed or unmanaged.

As you can see we have been adding more capabilities to the CLI. Our team has been actively working on making our Azure DevOps tasks to also be based on the Power Platform CLI, instead of the current PowerShell modules. We will be pushing out that update in early July, and in most cases those that are using your existing Azure DevOps pipelines should not notice any difference. The benefit of this work is that both GitHub actions and Azure DevOps tasks will be powered by the same engine and be cross platform.

As always, we are excited to bring these capabilities to you. If you have additional feedback please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode

The post Power platform Developer tools May Refresh appeared first on Microsoft Power Platform Blog.

Solution command updates

In this release pac solution unpack and pack will also unpack Canvas apps using the parameter –processCanvasApps. This is still a preview capability, but from this point on, users will not have to first unpack the solution and then issue a separate command for unpack Canvas Apps. The canvas library to unpack the canvas app has been upgraded to 0.45-preview version.

Publish customizations asynchronously. Before when users published their changes, in cases where solutions were too big, users had to wait, now we have changed this functionality to asynchronous, which improves the overall performance of this capability

This capability I am really excited about, solution upgrades until recently, there was no way to verify that the solution in the target environment was upgradeable. Now pac solution upgrade does a check in the target environment before proceeding with the upgrade. No more the situation where you realize you can’t upgrade the solution in the target environment only after the upgrade fails.

Packaging updates

The packaging construct within Power Platform allows a user to bundle multiple solutions into a package and can be deployed all together as one unit. This is particularly useful when you are making your application available via AppSource. Now we have updated the command to support applications that you develop for Teams and One Dynamics and One Platform.

The pac package init capability now defaults package project as an SDK style project that can be used from within Visual Studio or Visual Studio Code

You can also add pre-built solution.zip files to the package, instead of having to build from source.

Administration improvements

For the administration commands, you can now create, update, and delete Microsoft Teams environments.

The pac admin backup command –notes parameter has been deprecated in both the command line and the service endpoint. You can still use your old automation scripts but, please start working on migrating to this capability. If you do provide the –notes the command will emit a warning and it will be ignored.

As always we are excited to bring these capabilities to you. If you have additional feedback please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://aka.ms/powerplatform-vscode

The post Power Platform Command Line: New Updates (April Refresh) v1.15.x appeared first on Microsoft Power Platform Blog.

We would like to proudly announce that the Dataverse service client is now Generally Available for developers to use. Dataverse Service client has been in preview for a while, which is why this announcement gives us joy to provide developers with a Generally Available version of this SDK.

How is this different from the CRM Service Client SDk?

The developer community has been building immensely powerful applications using the CRM Service Client SDK. This new Dataverse Service Client SDK has the following capabilities, which enables the community to extend the value of their applications:

• Cross platform SDK based on .net core.
• Removed Dynamic Dependencies
• Works with the Dataverse Web API
• Targets cloud only Dataverse instances.

One thing to note is that the Power Platform Command line already uses the Dataverse Service client and has been doing that since it was available. Even the GitHub Actions infrastructure uses this SDK, and as of this Azure DevOps tasks are no longer PowerShell based, the Power Platform Command line based …. So, our Azure DevOps tasks use it too!

What are some of the resources available to get started?

Considerations to undertake as you transition your applications from the CRM Service Client to the Dataverse Service Client

https://docs.microsoft.com/en-us/power-apps/developer/data-platform/sdk-client-transition

Sample code to get started.

https://github.com/microsoft/PowerApps-Samples/tree/master/cds/orgsvc/C%23-NETCore/ServiceClient

SDK API reference documentation

https://docs.microsoft.com/en-us/dotnet/api/microsoft.powerplatform.dataverse.client?view=dataverse-sdk-latest

GitHub Repository of the SDK itself

https://github.com/microsoft/PowerPlatform-DataverseServiceClient

As always you can provide us feedback on the GitHub repository’s issue infrastructure. If you have additional feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community.

The post Dataverse Service Client is now Generally Available appeared first on Microsoft Power Platform Blog.