Cli-microsoft365: New command: Package a PowerApps Component Framework solution project

[YannickRe]

Packages a PowerApps component framework solution

pa solution package

Equivalent to the PowerApps CLI command.

[waldekmastykarz]

Updated description slightly

[YannickRe]

I think I figured out how to avoid msbuild for this command. With some slight tweaks to the generated *.pcfproject and *.cdsproject files (targeting netstandard2.0 and having dotnetcore2.2 installed, we can use dotnet to build the projects instead of msbuild.
As a result, #955 might not be necessary anymore since dotnet by default restores dependencies first (unless used with --no-restore flag).

It's just preliminary testing on Windows, still have to check behavior on macOS but since dotnet is supposed to be cross-platform, there shouldn't be an issue 😉

What's left now is figuring out how I can start dotnet from Office365 CLI. Any pointers would be awesome, otherwise I'll investigate some more and report back on possible solutions.

[VelinGeorgiev]

You can run dotnet core as sub process running inside nodejs. We do that for storing creadential in the windows credentials manager here.
As long as your dotnet exe is part of the project you can call it in a child process.

[YannickRe]

Hmm, that would mean packaging the dotnet.exe in the Office365 CLI (specifically the 2.2 version).
I need to investigate this further, it needs to be cross platform etc. My preference would be to not include it, I think, and put it as a prereq to use this command.

[VelinGeorgiev]

Well that could be a subject of discussion with @waldekmastykarz. My opinion is that would be nice if we can bundle it together with the dotnet core run-time and add it to the project so the users would not be asked to install another thing as prereq.

@waldekmastykarz what do you think?

[waldekmastykarz]

I agree with @YannickRe here: I don't think we should embed dotnet for every platform where you could run the CLI. We could include instructions, but ideally, if we offer a command to package a project, then we should implement it ourselves. The same way we don't ask folks to install PowerShell Core to run some commands :)

[YannickRe]

The way I see it, we have the following options for this:

1. Include DotNet Core CLI inside the Office 365 CLI
2. Imitate the process DotNet Core CLI does inside the Office 365 CLI
3. Don't create this command in Office 365 CLI (it doesn't exist in the office CLI either, they also say to run msbuild directly).
4. Run DotNet Core CLI from Office 365 CLI if it can be found on the system. If not found, provide instructions on how to acquire it.

My opinion:

1. Not the best thing for maintainability
2. Very difficult, we'll need to deepdive into the build steps and what msbuild actually does now
3. It's more difficult for us/less user friendly to provide this guidance through docs only
4. My preferred option, as it keeps everything in the CLI (users don't have to return to the docs) and provides the installation info if necessary

@waldekmastykarz @VelinGeorgiev You can agree on option 4? Or you see a different approach that I didn't consider?

[waldekmastykarz]

My preference would be 2 although I can imagine that as the build evolves over time, we could hit a block.

If we were to settles for 4, what's the added value of having a command for it as opposed to let folks just run msbuild against the project? Is the packaging of the generated artifacts so complex that having a command would be a significant benefit?

[YannickRe]

I agree option 2 would be the best option, but it's not something I think is fun or maintainable. While the end result looks very simple, I feel we're taking on a complexity that will bite us later.

The commands would be /t:rebuild /restore /p:PcfForceUpdate=true /p:Configuration=Debug when you have Visual Studio installed, or dotnet build -p:PcfForceUpdate=true --configuration Debug when using .NET Core. Most developers have run more complex commands before.

Reasons I see an added value for the command in O365 CLI:

• Provide an end-to-end solution within the CLI. People don't need to refer back to our documentation or the official documentation (which doesn't list the .NET Core command, only the MSBuild). We'd be providing an "in-app" experience.
• The new command pac pcf push (import a PCF control into a CDS organization for testing) first builds using one of those commands before it uploads it to CDS. If we'd like to support this new command in the future, we'll need to do the same.

I fully realize this might not be convincing for now 😀.

[waldekmastykarz]

I understand the added value but I'm still hesitant taking in other dependencies that could change in the future and could render the command useless altogether.

How about we try to investigate the complexity of the current build and see if it's something that we could replicate. Perhaps it's not as bad as we think and it's something that we can address with little effort avoiding unnecessary complexity.

[YannickRe]

Everything MSBuild does looks bad to me 😀 I agree it's a good idea to investigate first, but hopefully someone is willing to pick this one up. My skillset doesn't cover MSBuild, I'm afraid.