pac pcf push FAQ

[Craig-MSFT]

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
      and/or
      ‘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

[ScottDurow]

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.

[DianaBirkelbach]

This helped a lot. Thanks 🙂

I would still have a question. I understand that ‘pcf push’ doesn't replace the need for a cdsproj, but is it a bad practice to make a solution from scratch using the web interface and add there the pcf component from the PowerAppsTools_XXX solution? If I shouldn't work this way, can you please tell me what are the reasons (content for production?, manifest version?, do I risk not to be able to upgrade later on?).

In my case I only need the unmanaged solution with my pcf component. It will be used inside another solution which has to be delivered managed, and we wouldn't like to have dependencies on the solution containing the pcf component.

Generally speaking, I also have some problems with the generated solution (using the cdsproj: pac solution --init) because I miss some flexibility ( it takes the name of the directory, the generated solution zip name also doesn't have the version in the zip name), so I wonder if I can avoid it.

[Euclides]

Is there a way to set the what would be the Name, Display Name and Publisher before pushing the unmanaged solution to environment?

[Anonymous]

I find the solution management aspect of pac overly cumbersome. It would be a lot better if you could use pac pcf push to upload a production build (rather than it being forced to be a development build). Afterwards, all you have to do is add the PCF control as an existing component to another solution, no need to mess around with the solution management functionality in pac.