PowerClient looks very exciting as a way to solve the perennial client/server problem of deploying code to clients! But I have questions about a couple of aspects that are making me think it’s not something we can use yet.

I haven't had any hand-on experience playing with PowerClient myself yet, so if I'm wrong -- great! Otherwise, I guess this boils down to a feature request post.

Roaming Profiles

In Chris Pollach’s Elevate session, we see that the App Shell is installed into the user’s \AppData\Local folder, but it appeared that the PB applications and runtime(s) were installed into \AppData\Roaming. For enterprises implementing Roaming Profiles, doesn’t this mean that all of that data is being pushed up to the profile server and then synchronized with the workstation on each login/logoff?

Our current deployed executable folder, which includes runtime dlls and exe/pbds, weighs in at almost 300 MB. Of that, more than 100MB is our application (exe + pdbs).

If each of our several hundred users are going to need to store that much data on the profile server, this is probably a non-starter for us, especially since we maintain multiple environments that correspond with code branches/releases, so some users (developers, QA, beta testers) will be running multiple versions of our app at the same time. (I presume we would need to publish those as separately named applications: AppName, AppName_QA, AppName_Beta, etc.)

When stored in the new deployment format (individual object files) can we expect the application footprint be larger or smaller on disk than current binaries?

Is there any way to configure that the deployed applications get installed into AppData\Local instead of AppData\Roaming?

Integration with automated build pipelines

I saw that PowerClient is not yet supported by the command-line PBC tool. Does that mean the ORCA interface doesn’t support it yet either? Until PowerClient deployments can be automated as part of a CI/CD pipeline (we use TFS and PowerGen), I’m having a hard time working out how this could fit into our process.

For auditability, the builds we hand off to QA, and that get certified for production, must be generated by the build server, to provide some assurance that all objects came directly from source control. As long as PowerClient deployments require a developer (or someone with a PB license) to manually build from local PBLs, that chain of custody from source control to production is broken.

Let me know if I’m missing something, but this also sounds like a show-stopper for us.

First launch experience

Chris showed that the first time the end user loads the application URL, the user is prompted to download and install the App Shell. I was disappointed that the installer didn’t immediately launch the PB app after that install completed. Chris had to go back to the browser and navigate to the URL again.

This one’s not a show-stopper by any means (in fact we would probably push the App Shell to clients separately in advance), just a suggestion: I think it would fit better with users’ expectations, and maintain the illusion of an application being “at” a URL, if the application always launched from the URL -- whether it’s the first time or not.

Thanks in advance for any clarification anyone can provide.