Showing results for 
Search instead for 
Did you mean: 
Power Apps Staff Craig-MSFT
Power Apps Staff

pac pcf push FAQ

Why was ‘pcf push’ added?

The key goal was to speed up the PCF developer's inner loop, to help you move more quickly through your fix-build-test cycle. Prior to this feature, getting your PCF control into your org involved building your full solution and manually importing it. (The ‘npm start watch’ feature was also added due to this focus on speeding up the inner loop.)


What about the version in the Control Manifest?

When a solution with PCF is imported, the system looks at the version specified in the control manifest and only imports the control if the version in the incoming control is higher than the control that exists in the org. This mechanic is designed to be used as a part of your overall solution ALM, but it felt like it was getting in the way of the developer inner loop. We didn't want you to have to keep bumping the version in your manifest as you coded your control.


When you use 'pcf push,' the version check is skipped, and the control built from your source code is imported over the top of what is in the org.


Will ‘pcf push’ always succeed?

There are cases when ‘pcf push’ will fail. The case that most folks may hit is if you make a change to the manifest that adds or removes properties that are required or bound. One workaround for this is to first remove the control using the Web UI and then run ‘pcf push’ again.


Can ‘pcf push’ be used to deploy to production?

The 'pcf push' command will only build and deploy an unmanaged version of your control. It is not designed to be used for production, where managed solutions are recommended.


What is this new solution I see called PowerAppsTools_XXX?

The ‘pcf push’ command creates a temporary solution for the purposes of importing the project’s control. This temporary solution is written to the $\[projectdir]\obj directory and is always named “PowerAppsTools_[publisher-prefix]”. You can delete it once you are done using ‘pcf push’ for that PCF project. Deleting this temporary solution will not delete the control it contains.


Why do I need to specify the publisher prefix when using ‘pcf push’?

A change was recently made to how PCF controls are named, and their full name in the solution now includes the publisher prefix like many other components in CDS. In order to avoid name collisions, you need to specify the same publisher prefix that will be used in the solution that will deploy the control.


Does ‘pcf push’ replace the need for a cdsproj?

No, they are designed to be used in different parts of the development lifecycle.


The ‘pcf push’ command only imports one control at a time and only as unmanaged.


The cdsproj (or solution project) is there to help you build all the components in your solution, both managed and unmanaged. It performs a similar function to what SolutionPackager /pack does, but is integrated with build and is aware of the need to pull in the currently built bits of your control before packing (assuming you have added a reference with ‘solution add-reference’).


How should I use these features together?

Here is one possible way that development could proceed.

  1. Use ‘pcf init’ to create your control
  2. Inner Loop
    1. Code
    2. Build
    3. ‘npm start’ and test with local harness
      ‘pcf push’ and test in live Org
  3. When control is ready to be added to your solution…
  4. If you don’t have a solution, use ‘solution init’ to create your solution project
  5. For your new or existing solution, use ‘solution add-reference’ to add the pcf project to your solution
  6. Build your solution managed or unmanaged
  7. Import and test your managed or unmanaged solution


What if I have multiple PCF projects?

You can use the ‘pcf push’ command against multiple PCF projects. If these controls use the same publisher prefix, then they will end up under the same temporary solution. Any controls that use a different publisher prefix will end up under a different temporary solution.


For example, you might see these solutions and controls after running 'pcf push' against a few projects:

  • PowerAppsTools_prefix1
    • prefix1_mynamespace.testcontrol1
    • prefix1_mynamespace.testcontrol2
  • PowerAppsTool_prefix2
    • prefix2_mynamespace.testcontrol3
Level 8

Re: pac pcf push FAQ

It would be great if we could have the ability to push a new version of a control to update the manifest using pac push. Currently, we get an error if the version number of the control is different than deployed.

Helpful resources


Power Apps Community User Group Member Badge

Fill out a quick form to claim your user group badge now!


Power Platform World Tour

Find out where you can attend!

Power Platform 2019 release wave 2 plan

Power Platform 2019 release wave 2 plan

Features releasing from October 2019 through March 2020


Difinity Conference

The largest Power BI, Power Platform, and Data conference in New Zealand

Top Kudoed Authors (Last 30 Days)
Users online (5,716)