pac solution sync should accept a mapping file

[bguidinger]

The pac solution sync command should accept a --map parameter like the pac solution unpack command does. This way a solution mapping file can be used. Without this, when we run pac solution sync, it places the plugin assembly DLL and web resource files in the solution folder. However, we normally build those via our CI/CD pipeline and use the mapping file to "inject" them into our solution when we pack it.

[devkeydet]

If you use cdsproj, it accomplishes what map.xml does historically, but only for dlls and pcf today. We still have full parity a gap with web resources. Have look at this repo: https://github.com/devkeydet/HelloFusionDev. We are trying to encourage people to move away from map.xml and use the more modern approach to accomplish the same thing with cdsproj. But I acknowledge the gap with web resources and the general feedback. The repo I link to above does use map.xml for web resources, but via a cdsproj file. We can definitely improve the overall experience. Have a look at the repo and let's keep the discussion going. BTW, I moved this to a discussion and not an issue. We generally prefer enhancement requests start as discussions.

[devkeydet]

[bguidinger]

Thanks, Marc! I've added the SolutionPackageMapFilePath tag in my .cdsproj, and it works great when doing a dotnet build. However, the mapping file isn't respected by the pac solution sync command. Maybe I'm still missing something? My scenario is this:

1. Pull changes from Azure DevOps.
2. Run dotnet build to build the latest unmanaged solution.
3. Run pac solution import to import the solution to a dev environment.
4. Make changes via the Maker Portal.
5. Run pac solution sync to bring those changes back into my local repo.
6. Push changes back to Azure DevOps.

However, when doing this, it still wants to include the exported plugin assemblies and web resource files in the solution folder. To work around this, I have a PowerShell script which exports the solutions and runs the unpack with the mapping file.

pac solution export --name solution --async --overwrite --path ./Solution.zip
pac solution export --name solution --async --overwrite --path ./Solution_managed.zip --managed
pac solution unpack --zipfile ./Solution.zip --allowDelete --allowWrite --clobber --packagetype Both --map ./mapping.xml --folder ./src

I'd love to see a web resource project that ties into the .cdsproj. It would be especially awesome if it was pre-configured to use TypeScript, @types/xrm, minifying/optimizing for production builds, etc. Looking forward to any developments in this area. Let me know if you need any beta testers, I'd be happy to help out!

P.S. you should update the README so it asks to start feature requests as Discussions. Right now it says, "[we] do welcome your suggestions via this repository's issue tracker."

[devkeydet]

Yes, pac solution sync is one of the known gaps I was alluding to. I definitely agree with you in principle. For the most part, it's a matter of when. I've wanted something like this myself before joining the team. Something like...

pac webresource init (that can then be used with pac solution add-reference)
pac webresource push

All "just works" with dotnet build and pac solution sync. It's something we'll continue to consider, but don't have timelines right now.

[scottdurow]

Love this discussion 😍 Would be amazing if pac solution sync could honor the SolutionPackageMapFile in the cdsproj. After all, pac solution sync is using the cdsproj already!

I've also had to find work arounds like you @bguidinger. My approaches are:

1. Add the .js. and .dll files to the .gitignore to prevent them from being committed to source control after the sync. This still doesn't prevent a pack from accidently picking up a 'stale' binary/transpiled .js file
2. In the powershell script that does the pac solution sync add an additional step after to go and delete any .js and .dll files that have been brought down. This makes sure that any dotnet build will never succeed if the TypeScript and Plugin assemblies fail to build - which I feel is important.

Making sure that pac sync never brings down the built artefacts would ensure that developers always have to re-build from source when packing the solution.

I wonder how the sync is working from the inside - is it re-using the same code as the SolutionPackager? If it is then maybe it is just a case of passing the map path from the cdsproj https://learn.microsoft.com/en-us/power-platform/alm/solution-packager-tool#use-the-map-command-argument

[Lukis]

Quick clarifying question. I think I haven't been as active doing web resource development recently... I need a bit more context. Do we need to understand @bguidinger's use case more? I read the example, but if we are using/doing web resource changes IN the maker portal (not sure how, maybe classic UI?) what scenarios fit that development flow? Especially if we're talking about using typescript. As a developer advocate, I want them IN the IDE as much as possible, not clicking around in the UI.

In shared dev environments, our preference has always been fiddler for fastest development feedback, there's no deploy/publish wait time. Yes, it can be a little tricky to setup but it's an investment I believe is worth making and protects the current environment for others. Then for deployment, my ideal scenario is to perform a PR, and use pipelines to deploy to dev for consistency.

In solo development environments, it would be awesome if the same pcf sandbox could be used to do automatic deployments to dev, without the solution framework. The pcf deployment time is pretty slow. Reminds me of the XKCD cartoon where the boss says to get back to work and the devs respond 'compiling'.

[devkeydet]

Working on a PR internally to add --map to pac solution sync and pac solution clone. Stay tuned. I'd still like to add something like:

pac webresource init (that can then be used with pac solution add-reference)
pac webresource push

Doing so would make it easier to scaffold, generally set up, and work more consistently with how pcfproj/csproj work with cdsproj, but for web resources. But at least for those who understand map.xml...
https://learn.microsoft.com/en-us/power-platform/alm/solution-packager-tool#use-the-map-command-argument
...adding --map to pac solution clone and pac solution sync gets you closer to what you want.

[devkeydet]

PR merged to main internally. Stay tuned for the next release of pac cli to have this enhancement. It will show up in the release notes as:

solution sync
- Now supports `--map` to skip items in the unpack process (https://github.com/microsoft/powerplatform-build-tools/discussions/832)
solution clone
- Now supports `--map` to skip items in the unpack process (https://github.com/microsoft/powerplatform-build-tools/discussions/832)

https://www.nuget.org/packages/Microsoft.PowerApps.CLI#releasenotes-body-tab

[bguidinger]

Thanks, @devkeydet! I see it's published now. I appreciate your quick turnaround on this. I'll let you know if I face any issues with it.