Forem: Riccardo Gregori

Power Pages SPA Learning By Doing - Keep it clean

Riccardo Gregori — Sun, 22 Mar 2026 15:09:23 +0000

Lately, I’ve been working a lot with Power Pages Single Page Applications (SPA).
I find this approach far more effective than the previous one, and its potential, combined with GitHub Copilot’s ability to generate React code, makes portal development faster, more efficient, and honestly even fun 😎.

Power Pages SPA reached General Availability at the beginning of February, almost two months ago, but even today the official documentation is still not fully exhaustive. Many things can only be discovered by hands-on experimentation with the platform.

This article — or rather, this series of articles — is born with the goal of sharing the pain points and hidden gems I’ve encountered during my personal journey exploring this new technology.

So… what are we waiting for?

Let’s get started! 🚀

🤔 The issue - Stale files generated by chunking strategy

If you build a Power Pages SPA using React+Vite, as in this tutorial, every time you build your portal via:

npm run build

Build process automatically splits your site source code in a set of chunked files

The random-looking hashes in chunk names change because Vite uses content hashes by default. This means that when you change the content of your site, each chunk content may change, thus the chunk name changes too.

Those chunks become Web Files records in dataverse, that are created or updated when you type:

pac pages upload-code-site --rootPath .

Exactly... that command, by itself, adds or updates Web Files, but does not remove old, now unused, files.

On the medium-long run, this is a real issue, because your site definition will be crowded by tens or thousands of useless Web Files, that you will deploy between environments.

💡 How to fix it?

📌 Step A. Apply deterministic names on chunks

To avoid generate random-looking hashed names, you can customize how Vite produces the output files, with different possible strategies:

Important notice: these strategies are tested with Vite 7.3.1. Vite 8 (released March 2026) may require a different approach.

1. Disable hashing entirely (simplest)

In vite.config.ts, override the rollupOptions.output naming:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        // Static names — no hashes at all
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
      },
    },
  },
});

This gives you fully predictable names like index.js, vendor.js, etc. The downside is no cache-busting, but for Power Pages/ALM this is often exactly what you want.

2. Use a fixed/stable hash (content-based, but stable)

If you want hashes but want them to only change when the content actually changes (which is actually Vite's intent, but chunk splitting can cause cascading renames):

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].[hash].js`,
        chunkFileNames: `assets/[name].[hash].js`,
        assetFileNames: `assets/[name].[hash].[ext]`,
      },
    },
  },
});

The issue here is usually not the hash algorithm but chunk splitting — if Rollup splits chunks differently between builds, names drift. Fix that with option 3.

3. Pin your manual chunks (most robust for ALM)

The real culprit is often Rollup's automatic code splitting producing differently-named dynamic chunks. Lock it down with manualChunks:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
        manualChunks: {
          // Pin vendor libs into a stable named chunk
          vendor: ['react', 'react-dom'],
          // Add other large deps as needed
          // router: ['react-router-dom'],
        },
      },
    },
  },
});

This way Rollup won't invent new chunk names — you've explicitly defined the boundaries.

4. Disable code splitting entirely (nuclear option)

If the SPA is small enough, just bundle everything into one file:

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        inlineDynamicImports: true, // single bundle
        entryFileNames: `assets/index.js`,
        assetFileNames: `assets/[name].[ext]`,
      },
    },
  },
});

Recommended approach for Power Pages

In the end I've decided to combine options 1+3, that work for my needs.
Considering that I'm using the following libraries:

fluentui: for ui components of my website
react-router-dom: to handle url routing in my SPA
powerbi-client-react: to embed powerbi reports on the site
react-google-charts: for home page charts
adal-angular: to manage authentication

This is (part of) my vite.config.ts:

export default defineConfig({
  plugins: [react()],
  base: '/', // absolute path - Power Pages handles routing
  build: {
    ...
    rollupOptions: {
      output: {
        entryFileNames: `assets/[name].js`,
        chunkFileNames: `assets/[name].js`,
        assetFileNames: `assets/[name].[ext]`,
        manualChunks: {
          router: ['react-router-dom'],
          fluent: ['@fluentui/react-components', '@fluentui/react-icons'],
          powerbi: ['powerbi-client-react'],
          charts: ['react-google-charts'],
          adal: ['adal-angular'],
        },
      },
    },
  },
  ...
});

This gives me a fixed, known set of filenames that map 1:1 to my Power Pages Web Files, and they only change if you explicitly add a new manualChunks group.

🧹 B. Good, but now how I get rid of the old files?

A small hint on how to fix it is given by pac pages upload-code-site command itself. When you run it, it says:

Found 10 bundle pattern(s) to match for cleanup:
1. main .*. js
3. vendor .*. js
4. vendor .*. css
5. chunk -*. js
6. chunk -*. css
7. bundle .*. js
8. bundle .*. css
9. index -*. js
10. index -*. css

Note: You can customize these patterns by adding 'bundleFilePatterns' array in 'powerpages.config.json' file.

So, even if isn't documented anywhere, it seems it tries to clean up the mess before pushing, and it seems we can tweak the powerpages.config.json file to customize it's behavior. After a few tests, I've found that if you add a bundleFilePatterns node with an array of file patterns, those are "pruned" by pac pages upload-code-site before being replaced by the new bundles generated from your build.

In my case, the configuration that works is the following:

{
  "siteName": "my-site-name",
  "defaultLandingPage": "index.html",
  "compiledPath": ".\\dist",
  "bundleFilePatterns": [
    "main.*.js",
    "vendor.*.js",
    "vendor.*.css",
    "chunk-*.js",
    "chunk-*.css",
    "bundle.*.js",
    "bundle.*.css",
    "index-*.js",
    "index-*.css",
    "index.*.js",
    "index.*.css",
    "FluentSystemIcons-Filled.*.woff2",
    "FluentSystemIcons-Filled.*.woff",
    "FluentSystemIcons-Filled.*.ttf",
    "FluentSystemIcons-Light.*.woff2",
    "FluentSystemIcons-Light.*.woff",
    "FluentSystemIcons-Light.*.ttf",
    "FluentSystemIcons-Regular.*.woff2",
    "FluentSystemIcons-Regular.*.woff",
    "FluentSystemIcons-Regular.*.ttf",
    "FluentSystemIcons-Resizable.*.woff2",
    "FluentSystemIcons-Resizable.*.woff",
    "FluentSystemIcons-Resizable.*.ttf"
  ]
}

And it works... it effectively removes all stale files from your local .powerpages-site folder, and when pushed to Dataverse, those file are removed from there as well... or at least, 90% of them.

🖖🏼 C. Let's finish by hand

Even after tweaking the vite.config.ts and the powerpages.config.json, I've found a few files that still remain on my Dataverse environment.

Frankly I think it's a bug of PAC CLI. The only solution I've found is to remove them manually, hoping they won't be re-generated again thanks to

Please note: when you do it, you may occur in the following non-blocking-error while running:

XRM Network error: An error occurred in the PowerPageComponentDeletePlugin.

The only solution I've found to solve this issue is to edit manually the file called .portalconfig/my-site-url-manifest.yml.

You need to:

use Plugin Trace Viewer XrmToolBox Plugin to get all exceptions coming from plugin Microsoft.PowerPages.Core.Plugins.PowerPageComponentDeletePlugin
from the trace message, extract the GUID of the missing component.

search for that GUID into file .portalconfig/my-site-url-manifest.yml and remove the yaml section referring to it. It should be similar to the following.

# sample block to remove
- RecordId: f9d754fb-4b71-4491-bad7-7c06eb21bce5
  DisplayName: index.COcDBgFa.css
  CheckSum: fa7ab4d0d9716e5ae809c29050b94cdaf004c4c51e1f35241716333b1352fb4a
  IsDeleted: false

You may also want to find all lines with IsDeleted: true and remove them, and also clear the contents of the .portalconfig/manifest.yml file (that contains only references to deleted files).

🎯 Final considerations

Power Pages SPA is a huge step forward compared to the classic portal model, especially if you come from a modern frontend background. Being able to bring your own React stack, use Vite, and rely on tools like GitHub Copilot dramatically changes the developer experience and the delivery speed.

That said, today’s reality is that Power Pages SPA is still a young product. Some important behaviors — like how bundles are handled, how cleanup works, and how Dataverse Web Files are managed over time — are either underdocumented or not documented at all. As a result, production-ready solutions still require a fair amount of experimentation, reverse‑engineering, and sometimes even manual intervention.

The chunking issue described in this article is a perfect example:
nothing is technically broken, but without deterministic filenames and explicit cleanup rules, you end up with a slowly degrading site definition, polluted by stale Web Files that get deployed across environments and make ALM harder than it should be.

My personal takeaway so far is:

Treat the build output as a contract: Stable filenames and pinned chunks are not optional in enterprise scenarios — they’re a prerequisite.
Assume PAC CLI cleanup is best‑effort, not authoritative: bundleFilePatterns helps a lot, but today it doesn’t guarantee a 100% clean state.
Expect to occasionally "drop below the abstraction": Editing manifests and cleaning Dataverse artifacts by hand shouldn’t be necessary — but right now, it sometimes is.

Despite all of this, I still strongly believe Power Pages SPA is the right direction. The flexibility it gives you largely outweighs the current rough edges, especially if you’re already comfortable with React, modern bundlers, and CI/CD pipelines.

Hopefully, future iterations of the platform — and better documentation — will make many of the workarounds shown here obsolete. Until then, knowing where the sharp edges are is the key to using this technology effectively.

In the next articles of this series, I’ll dive into other real-world issues and patterns I’ve encountered while building Power Pages SPAs — from authentication quirks, to CSP constraints, to deployment strategies that actually scale.

Stay tuned 🚀

Simple, but yet rock hard, truth.

Riccardo Gregori — Mon, 02 Mar 2026 22:20:43 +0000

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

#discuss #mentalhealth #webdev #career

Greg.KeySub – The Ultimate Revenge Against the Italian Keyboard

Riccardo Gregori — Mon, 09 Feb 2026 21:42:04 +0000

There’s a group of people who have been silently suffering for years.
A forgotten minority, ignored by institutions, abandoned by the tech industry, left behind even by Microsoft, Apple, and the United Nations.

I’m talking about us: Italian developers forced to use the Italian keyboard layout.

Yes, that one.

The one that gives you the incredibly useful “§” key, which you have never pressed voluntarily in your entire life, but denies you the most fundamental character of the modern software era:

The backtick: `

The backbone of Markdown.
The unsung hero of code snippets.
The vital organ of shell commands.
A character so essential that GitHub should send you a condolence letter every time you try to write documentation with an Italian keyboard.

The Italian layout? It simply forgot it. Oh, but it has plenty of "useful" keys such as "§" or "ç"...

Every Italian developer has faced at least one of the following situations:

Typing ALT+96 with the elegance of a musician playing the piano with their elbows.
Juggling with WIN+. > move to chars > select the `
Googling “backtick” just to copy and paste the damn symbol.

So… I decided to stop suffering.

I did what any developer does when reality refuses to cooperate:
I wrote a tool to bypass reality entirely. Or better, I vibe coded a tool to save me hours per week.

Introducing: Greg.KeySub

Available here:

👉 https://github.com/neronotte/Greg.KeySub

Greg.KeySub is a tiny Windows tool that quietly lives in your system tray — right next to a few utilities, five unnecessary Electron apps, and three icons whose meaning you’ve forgotten years ago.

Its one and only job?

Listen to the keys you press, and whenever you hit that useless §, it magically transforms it into a glorious, essential, life-improving `.

Yes, you read that right: § becomes `.

Because that key had no purpose. None.
Now, finally, it serves a higher mission.

Why You Should Install It Right Now

🎯 Because it saves time.
Write Markdown like a normal person, not like someone performing finger acrobatics.

🔥 Because it gives purpose to a key that had none.
Digital recycling at its finest.

😤 Because the Italian keyboard layout will never fix itself.
Let’s be honest. It’s been decades. It’s not happening.

⭐ Because it’s open source.
You can contribute, improve it, fork it, or just stare at the code thinking “I would’ve done it differently.”

Install it, try it, love it ❤️

Find it here:

👉 https://github.com/neronotte/Greg.KeySub

If you’re an Italian programmer who writes Markdown, this tool is like that 4 PM coffee: You didn’t know you needed it until you started using it.

Modern Power App development takes a lot of... SPACE.

Riccardo Gregori — Tue, 20 Jan 2026 22:03:37 +0000

🧠 The Paradigm Shift: Why We Don’t Argue UI Anymore

There was a time (you remember it) when any client request that drifted outside the "blessed" Power Apps patterns triggered a long conversation about platform constraints. We tried to reshape requirements, push standard controls, and hope stakeholders would accept a slightly clunky interaction with the UI in the name of long-term maintainability.

That era is over.

With AI-assisted development (hello my dear friend, GitHub Copilot), it’s now faster and safer to build small, targeted customizations—PCFs or React WebResources—than to litigate UX.

You can ship exactly what the client envisions, document it properly, and make it maintainable long-term. The payoff is huge: better UX → higher adoption → stronger platform stickiness. In other words, great UI is not a "nice-to-have"—it’s a retention strategy.

When you replace “discuss why we can’t” with “deliver what delights,” you:

Earn trust faster
Accelerate sign-off
Anchor the customer to the platform with experiences they love

But there’s a catch…

🧱 The Problem: A Dozen PCFs/WebResources = Disk Space Meltdown

React-based PCFs and WebResources lean on Node’s ecosystem. And Node’s ecosystem leans on… node_modules—the folder that eats hard drives for breakfast.

Every project carries its own dependency tree. Multiply that across 8, 12, 20 PCFs/WebResources… and your laptop screams. It’s common to see hundreds of thousands of files and tens (or hundreds) of GB consumed across projects.

Good news: there’s a clean, robust solution that many Power Platform devs underuse:

🧩 The Hidden Gem: NPM Workspaces

NPM Workspaces let you manage multiple packages/projects (PCFs/WebResources) under one repository, sharing a single top-level node_modules whenever possible. This dramatically reduces duplication and makes dependency management more predictable and CI-friendly.

Official docs: NPM Workspaces

What you get:

✅ One central node_modules (plus small per-package shims when needed)
✅ Shared tooling (TypeScript config, lint rules, build scripts)
✅ Shared local packages (@types/xrm, @fluentui/react-components) used across PCFs/WRs via workspace:
✅ Unified scripts (build, test, lint) across all packages
✅ Faster CI with a single dependency tree and cache

🤔 How Does It Works?

It's quite straightforward. All you need is to define a package.json and a package-lock.json files at the root of your project folder, just above the folders containing PCFs and WebResources. This will make your project folder a monorepo.

📂 my-monorepo/
├─ 📄 package.json         <-- workspace root
├─ 📄 package-lock.json
│
├─ 📂 Pcf/
│  ├─ 📂 pcf1/
│  │  ├─ 📄 package.json
│  │  └─ ...
│  └─ 📂 pcf2/
│     ├─ 📄 package.json
│     └─ ...
│
└─ 📂 WebResources/
   ├─ 📂 webresource1/
   │  ├─ 📄 package.json
   │  └─ ...
   └─ 📂 webresource2/
      ├─ 📄 package.json
      └─ ...

It is important that the root package.json file contains the following:

{
  "name": "my-monorepo",
  "private": true,
  "workspaces": [
    "Pcf/*",
    "WebResources/*",
  ]
}

You can do it manually, or via:

cd my-monorepo
npm init -y

npm pkg set private=true
npm pkg set workspaces[0]="Pcf/*"
npm pkg set workspaces[1]="WebResources/*"

Then you can create your PCFs into the PCF and WebResources folder as usual... Just a tip: remember that the value of the name node of the package.json files under each of your PCFs/WRs must be unique, otherwise you'll get an error while running npm <whatever>.

When you'll run

npm install

All dependencies will be installed in a single, above all, node_modules folder created just under the my-monorepo folder.

NOTE: If two packages need different versions of the same dep, npm may place some deps locally. That’s fine; you’ll still save tons of space overall.

🗂️ A Practical Folder Structure for Power Platform Projects

Here’s a realistic example of the output folder you'll get, on a standard Power App project:

📂 project-folder
├─ 📄 .gitignore
├─ 📂 src
│  ├─ 📄 package.json
│  ├─ 📄 package-lock.json
│  ├─ 📂 node_modules
│  ├─ 📂 Pcf
│  │  ├─ 📂 NumericInputControl
│  │  │  ├─ 📄 package.json
│  │  │  ├─ 📄 package-lock.json
│  │  │  └─ ...
│  │  ├─ 📂 PurchaseOrderGrid
│  │  │  ├─ 📄 package.json
│  │  │  ├─ 📄 package-lock.json
│  │  │  └─ ...
│  │  └─ 📂 CustomTreeView
│  │     ├─ 📄 package.json
│  │     ├─ 📄 package-lock.json
│  │     └─ ...
│  └─ 📂 WebResources
│     ├─ 📂 HomePage
│     │  ├─ 📄 package.json
│     │  ├─ 📄 package-lock.json
│     │  └─ ...
│     └─ 📂 ControlDashboard
│        ├─ 📄 package.json
│        ├─ 📄 package-lock.json
│        └─ ...
└─ 📂 test
   └─ ... # other stuff

📉 How Much Space Do You Actually Save?

In Power Platform solutions with 8–20 React packages, we’ve seen:

60–80% reduction in duplicated dependency files
Build times drop (less overall I/O and fewer cold installs)

Your mileage varies with library choices, but the direction is always the same: less bloat, more flow.

🪄 Conclusions

AI copilot tools make building custom, crisp UX easy. NPM Workspaces make maintaining many customizations sane. Put them together and you’ve got a Power Platform development lifecycle that’s fast, clean, and—dare I say—fun.

Give it a try, and let me know in the comments what you think about it!

Automatically Refresh Forms After Status Changes in Model Driven Apps

Riccardo Gregori — Fri, 26 Dec 2025 14:16:52 +0000

When designing complex state models in Model Driven Apps, sometimes it can happen you need to "freeze" the possibility for the user to update a record data while some operation runs in background, and then make it editable again when the operation completes.

A few practical examples:

Document Generation and E-signature: A quote record triggers automatic PDF generation and sends it to DocuSign or Adobe Sign. While the document is being generated, sent, and awaiting signature, the contract terms should be locked. Once the signature is complete (or rejected), the form becomes editable again for next steps.
Credit Check Integration: When a customer service rep creates a new customer account, an external credit check service is called in the background. The form needs to be frozen while waiting for the credit score, payment terms recommendations, and risk assessment to return. You don't want users changing customer details while the credit bureau is still processing the original information.
Inventory Reservation in Order Processing: When an order is placed, a background process checks inventory across multiple warehouses and reserves stock. During this reservation process (which might involve calling external warehouse management systems), the order quantities should be frozen to prevent overselling or conflicts.
Compliance and Regulatory Checks: In healthcare or financial services, when a case is submitted, it might trigger automated compliance screenings (sanctions lists, fraud detection, regulatory reporting). The case details must remain locked during these checks to maintain audit trail integrity.
Data Enrichment from Third-party APIs: A lead record triggers enrichment processes pulling company data from LinkedIn, Clearbit, or Dun & Bradstreet. While these APIs are called and data is being validated and merged, you want to prevent users from manually entering conflicting information.

Typically, you can leverage the out of the box statecode and statuscode fields of the interested table to model the frozen statuses. If we take for instance the first example above, a possible state model for the quote table can be the following:

Logical Status	`statecode`	`statuscode`	Description
New	Active	New	The quote is being created and filled with data
Submitted	Inactive	Submitted	The quote has been submitted for the digital signature, the background operation is running
Signed	Active	Signed	The quote is open for post-signature steps (approvals, project generation, etc)
Cancelled	Inactive	Cancelled	The quote has been logically removed from the system
Sent	Inactive	Sent	Quote sent to the client
Won	Inactive	Won	The client accepted the quote
Lost	Inactive	Lost	The client has rejected the quote

Where the meaning of the statecode=Inactive is "not updatable by the user". I often prefer to change the label of that state to "Read only", as I find this wording less misleading and more intuitive.

If the trigger that changes the status to the inactive one comes from the form, we have a small UX problem: the form will be disabled (as required), the operation will run in the background (as required), but when the operation ends (after a couple of seconds, potentially), the user doesn't have any clue about the completeness. He needs to manually trigger the form refresh to see the changes to the current record.

Of course you can leverage MDA Push Notification system in the async workflow to notify the user but... he still needs to reopen the record to see the changes.

Fixing this UX issue is quite easy, you can just add a few lines of JavaScript in the form that:

runs only when the status changes to the inactive one you want to monitor
checks iteratively via WebApi for the status to change
when the status changes, refreshes the form data.

just like the following one:

class Form {
    formType = {
        Create: 1,
        Update: 2,
        ReadOnly: 3,
        Disabled: 4,
        BulkEdit: 6
    };

    statuscode = {
        New: 1,
        Submitted: 2
    }

    // Polling interval for status monitoring
    pollingInterval = null;

    onLoad(executionContext) {
        const formContext = executionContext.getFormContext();
        const formType = formContext.ui.getFormType();

        // Start auto-refresh monitoring if status is Submitted
        const status = this.statuscode.Submitted;
        this.startStatusMonitoring(formContext, status);
        formContext.data.addOnLoad(() => {
            this.startStatusMonitoring(formContext, status);
        });
    }

    /**
     * Starts monitoring the record status if it's in Initializing state
     * @param {object} formContext - The form context
     */
    startStatusMonitoring(formContext, status) {
        const currentStatus = formContext.getAttribute("statuscode").getValue();

        // Only start monitoring if status is Submitted
        if (currentStatus !== status) {
            return;
        }

        console.log("Starting status monitoring for Initializing record");

        // Clear any existing interval
        if (this.pollingInterval) {
            clearInterval(this.pollingInterval);
        }

        // Start polling every 2 seconds
        this.pollingInterval = setInterval(async () => {
            try {
                await this.checkStatusChange(formContext, status);
            } catch (error) {
                console.error("Error checking status change:", error);
                // Continue polling even if there's an error
            }
        }, 2000);
    }

    /**
     * Checks if the record status has changed and refreshes the page if it has
     * @param {object} formContext - The form context
     */
    async checkStatusChange(formContext, status) {
        const recordId = formContext.data.entity.getId().replace(/[{}]/g, "");
        const entityName = formContext.data.entity.getEntityName();

        try {
            // Retrieve the current statuscode from the server
            const result = await Xrm.WebApi.retrieveRecord(entityName, recordId, "?$select=statuscode");
            const serverStatus = result.statuscode;
            const currentFormStatus = formContext.getAttribute("statuscode").getValue();

            console.log(`Current form status: ${currentFormStatus}, Server status: ${serverStatus}`);

            // If status has changed from Submitted, refresh the page
            if (currentFormStatus === status && serverStatus !== status) {
                console.log("Status changed, refreshing page...");

                // Clear the polling interval
                this.stopStatusMonitoring();

                // Refresh the current window
                formContext.data.refresh();
            }
        } catch (error) {
            console.error("Failed to retrieve record status:", error);
            // Don't stop polling on API errors, as they might be temporary
        }
    }

    /**
     * Stops the status monitoring (useful for cleanup)
     */
    stopStatusMonitoring() {
        if (this.pollingInterval) {
            clearInterval(this.pollingInterval);
            this.pollingInterval = null;
            console.log("Status monitoring stopped");
        }
    }
}

Greg = window.Greg || {};
Greg.greg_quote = Greg.greg_quote || {};
Greg.greg_quote.Form = new Form();

Hope this helps you too!

How to: Fix WebResources Layout in Dataverse Dashboards

Riccardo Gregori — Tue, 18 Nov 2025 22:59:07 +0000

🤔 The problem

If you ever managed to create a Dataverse Dashboard containing an HTML WebResource (e.g. to show some calculated KPI), by default the resulting UI is quite ugly:

What I don't like:

Each WebResource component has a surrounding black border I would like to get rid of
The minimum vertical space that can be occupied by the WebResources row is 6 lines. Too much for my needs.

For both points, the Dashboard editor doesn't provides any option to fix the problem:

No option to remove the border

And I cannot reduce the vertical space

💡 The solution

As usual, the solution is quite simple via small XML tweaking.

Step 1. Create a new solution

In my case I already had a "ribbon" solution ready to use, thus in the screenshots below you'll see that one.

Step 2. Add the dashboard as the only component

Access the solution, then click on Add existing > Dashboard

And peek the dashboard you want to update (in my case, Tickets).

Step 3. Move to VS Code

In VSCode terminal, run the following PAC CLI command:

pac solution clone --name "<your solution unique name>"

PAC CLI will automatically download the solution and unpack its components in the current folder.

Step 4. Update the Dashboard XML definition

Access the dashboard xml definition you'll find at <solution name>\src\Dashboards\<dashboard guid>.xml

In the XML definition, find the WebResources controls. They can be easily found searching by the following string <control id="WebResource_.

You'll see something like this:

<cell colspan="1" rowspan="6" showlabel="false" id="{77846b48-5139-4c61-a5d1-fda39d80f21b}">
    <labels>
    <label description="KPI1" languagecode="1033" />
    </labels>
    <control id="WebResource_kpi1" classid="{9FDF5F91-88B1-47f4-AD53-C11EFC01A01D}">
    <parameters>
        <Url>prefix_/pages/dashboardkpi/index.html</Url>
        <Data>ticket_total_count</Data>
        <PassParameters>false</PassParameters>
        <ShowOnMobileClient>false</ShowOnMobileClient>
        <Security>false</Security>
        <Scrolling>auto</Scrolling>
        <Border>true</Border>
        <WebResourceId>{F30B702C-C9C4-F011-BBD3-7CED8D454E57}</WebResourceId>
    </parameters>
    </control>
</cell>

To remove the border, update the <Border> node to false.
To decrease the height, set the rowspan attribute to 3 (or adjust it as you wish).

Like this:

<cell colspan="1" rowspan="3" showlabel="false" id="{77846b48-5139-4c61-a5d1-fda39d80f21b}">
    <labels>
    <label description="KPI1" languagecode="1033" />
    </labels>
    <control id="WebResource_kpi1" classid="{9FDF5F91-88B1-47f4-AD53-C11EFC01A01D}">
    <parameters>
        <Url>prefix_/pages/dashboardkpi/index.html</Url>
        <Data>ticket_total_count</Data>
        <PassParameters>false</PassParameters>
        <ShowOnMobileClient>false</ShowOnMobileClient>
        <Security>false</Security>
        <Scrolling>auto</Scrolling>
        <Border>false</Border>
        <WebResourceId>{F30B702C-C9C4-F011-BBD3-7CED8D454E57}</WebResourceId>
    </parameters>
    </control>
</cell>

Step 5. Rebuild the solution in unmanaged mode

Open the terminal in the folder containing the <solution>.cdsproj file and run the following command:

dotnet build

it will generate the unmanaged version of the solution in the \bin\Debug subfolder of the current folder.

Step 6. Import the generated solution

Via PAC CLI:

# ribbon is the name of my solution, change it with your own
pac solution import -p .\bin\debug\ribbon.zip

Step 7. Publish all

This time, let's use PACX

pacx publish all

You can always do it the old way, via maker portal

😎 The result

Et voilà, the same dashboard, with both issues fixed ☺️

Hope this helps you too!

Model Driven App: disable "Open in Excel Online" button

Riccardo Gregori — Thu, 13 Nov 2025 16:17:20 +0000

🤔 The issue

The out-of-the-box Excel integration in Model Driven apps is a powerful, but very dangerous, feature.

Import from Excel, especially, can be very harmful because an user could leverage it to bypass any client side logic put on forms, generating inconsistent data within the system. Moreover, it cannot be customized: you cannot say "you can import opportunities records, but you cannot import accounts", neither you could say "import works only on columns A, B, C".

That's the reason why, in most of the CRM (and MDAs) implementations I've seen so far, the Import from Excel button is disabled for standard users, and replaced with custom data-import capabilities.

Disabling the Import from Excel button is quite easy, It just requires from you to remove the Data Import and Data Map privileges from the role assigned to users.

It works... more or less...

...even if the Data Import privilege is removed, you can have the possibility to open the "Export In Excel" > "Open in Excel Online" capability

With the edit capability enabled, and the Save button visible and clickable:

If you change something and click on Save, the following (ugly) error message appears (depending on the UI language of the user, mine is Italian)

That's a behavior that looks more like a bug than a feature, IMHO.

The best would be to disable that "Open in Excel Online" button too... tipically for specific users/roles. But there is no such option in the role privileges...

😖 Failed fix tentatives

If you try to hide the button using Ribbon Workbench or the Modern Ribbon editor, you will quickly see that's any customization on that button is disabled.

👍🏻 How to do it

For people like me, mold by CRM implementations before Ribbon Workbench, the fix is quite straightforward: let's tweak the RibbonDiffXml "the old way".

First of all, let's create a solution containing only the definition of the entity we want to disable that button for.

Then let's use Power Platform CLI commands to export and unpack the solution in a local folder

pac solution clone --name temp

It generates locally a structure similar to the following:

Let's open the RibbonDiff.xml file, it will be like the following one:

<?xml version="1.0" encoding="utf-8"?>
<RibbonDiffXml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <CustomActions />
  <Templates>
    <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
  </Templates>
  <CommandDefinitions />
  <RuleDefinitions>
    <TabDisplayRules />
    <DisplayRules />
    <EnableRules />
  </RuleDefinitions>
  <LocLabels />
</RibbonDiffXml>

In the <DisplayRules> node, let's add a rule that is evaluated to "true" only in the case an user is system administrator (here you can use your fantasy)...

<DisplayRules>
  <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule">
    <EntityPrivilegeRule PrivilegeType="Delete" PrivilegeDepth="Basic" EntityName="solution" Default="false" InvertResult="false" />
  </DisplayRule>
</DisplayRules>

Then, in the <CommandDefinitions> node, let's add the following

<CommandDefinitions>
  <CommandDefinition Id="Mscrm.ExportToExcel.Online">
    <EnableRules>
      <EnableRule Id="Mscrm.ExportToExcel.ValidForXlsxExport" />
      <EnableRule Id="Mscrm.EnableExportToExcelOnlineForModern" />
      <EnableRule Id="Mscrm.EnableOnlyInBrowsersForModern" />
    </EnableRules>
    <DisplayRules>
      <DisplayRule Id="Mscrm.Live" />
      <DisplayRule Id="Mscrm.IsExportToExcelFCBEnabled" />
      <DisplayRule Id="Mscrm.HideOnOutlookClient" />
      <DisplayRule Id="Mscrm.NotAdvancedFind" />
      <DisplayRule Id="Mscrm.HideOnPhoneForNonModern" />
      <DisplayRule Id="Mscrm.HideForTabletExperience" />
      <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule" />
    </DisplayRules>
    <Actions>
      <JavaScriptFunction FunctionName="XrmCore.Commands.Export.exportToExcel" Library="$webresource:Main_system_library.js">
        <CrmParameter Value="SelectedControl" />
        <CrmParameter Value="SelectedEntityTypeName" />
        <IntParameter Value="6" />
      </JavaScriptFunction>
    </Actions>
  </CommandDefinition>
</CommandDefinitions>

The final RibbonDiffXML should look something similar to the following:

<?xml version="1.0" encoding="utf-8"?>
<RibbonDiffXml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <CustomActions />
  <Templates>
    <RibbonTemplates Id="Mscrm.Templates"></RibbonTemplates>
  </Templates>
  <CommandDefinitions>
    <CommandDefinition Id="Mscrm.ExportToExcel.Online">
      <EnableRules>
        <EnableRule Id="Mscrm.ExportToExcel.ValidForXlsxExport" />
        <EnableRule Id="Mscrm.EnableExportToExcelOnlineForModern" />
        <EnableRule Id="Mscrm.EnableOnlyInBrowsersForModern" />
      </EnableRules>
      <DisplayRules>
        <DisplayRule Id="Mscrm.Live" />
        <DisplayRule Id="Mscrm.IsExportToExcelFCBEnabled" />
        <DisplayRule Id="Mscrm.HideOnOutlookClient" />
        <DisplayRule Id="Mscrm.NotAdvancedFind" />
        <DisplayRule Id="Mscrm.HideOnPhoneForNonModern" />
        <DisplayRule Id="Mscrm.HideForTabletExperience" />
        <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule" />
      </DisplayRules>
      <Actions>
        <JavaScriptFunction FunctionName="XrmCore.Commands.Export.exportToExcel" Library="$webresource:Main_system_library.js">
          <CrmParameter Value="SelectedControl" />
          <CrmParameter Value="SelectedEntityTypeName" />
          <IntParameter Value="6" />
        </JavaScriptFunction>
      </Actions>
    </CommandDefinition>
  </CommandDefinitions>
  <RuleDefinitions>
    <TabDisplayRules />
    <DisplayRules>
      <DisplayRule Id="greg.tablename.IsSystemAdmin.DisplayRule">
        <EntityPrivilegeRule PrivilegeType="Delete" PrivilegeDepth="Basic" EntityName="solution" Default="false" InvertResult="false" />
      </DisplayRule>
    </DisplayRules>
    <EnableRules />
  </RuleDefinitions>
  <LocLabels />
</RibbonDiffXml>

Now build the solution ad upload the generated solution zip file:

dotnet build
pac solution import --path .\bin\debug\temp.zip

Wait for the import to complete, then go to your environment, select the solution you just uploaded, and click Publish All Customizations.

Or, if you're using PACX in your project, simply type:

pacx publish all

That's it... Now that button will be visible only by System Administrator.

Hope this helps you too!

Dataverse MCP Server configuration failed...

Riccardo Gregori — Thu, 06 Nov 2025 20:35:04 +0000

If you want to configure the Dataverse MCP Server as described in the official Microsoft Learn article, you'll need to write in your mcp.json file an url with the following exact format (without the line breaks, of course):

https://make.powerautomate.com/environments/
59fd5b0e-f1e3-4f86-920d-509f44cb1846/connections
?apiName=shared_commondataserviceforapps
&connectionName=263a3d1e-1279-45f6-a593-070f9efaaad3

The tutorial instructs you to create a connection via make.powerautomate.com, and then take the URL from the connection page.

If you do it exactly as stated in the official docs, the URL you'll get has this form:

https://make.powerautomate.com/environments/
59fd5b0e-f1e3-4f86-920d-509f44cb1846/connections
/shared_commondataserviceforapps
/263a3d1e-1279-45f6-a593-070f9efaaad3/details

The fact is that URL, put in the mcp.json file, won't work 😡🤬.

You need to tweak the url manually in the following way:

take the first part of the url, from https:// to connections
replace the / after connections with ?apiName=
replace the / after shared_commondataserviceforapps with &connectionName=
remove the leading /details

And you're ready to go.

🙏🏻 Hope this helps you too!

💵 Dataverse Exchange Rates 101 💵

Riccardo Gregori — Mon, 03 Nov 2025 10:31:37 +0000

See the original post from Sabih Ahmed Khan

In Dynamics 365, exchange rates are not always recalculated automatically:

🔹 When Exchange Rate IS Applied

At the moment a record with currency fields is created.
When a money column in the record is updated.
When the state of the record changes (e.g., draft → submitted).

🔹 When Exchange Rate is NOT Applied

Simply changing a non-money field (like quantity) doesn’t trigger recalculation.
Viewing a record later still shows values based on the exchange rate at the time it was last assigned, not the latest rate.
Currency updates in the system don’t retroactively update existing records.

💡 Takeaway: Exchange rates are point-in-time values unless the record’s money fields or state are updated.

If you want to properly manage exchange rate values, see my previous blog post Update currency Exchange Rate in Dataverse... simplified! 😊

Generative Pages: The Right Hype, for the Wrong Reason

Riccardo Gregori — Sat, 25 Oct 2025 15:51:04 +0000

Lately, the Power Platform community has been buzzing with excitement over Generative Pages. Touted as a game-changer, they’re often presented as the long-awaited solution for building custom interfaces within Model-Driven Apps. And while the enthusiasm is understandable, I can’t help but feel that the hype is—at least partially—misplaced.

Let me explain.

🦄 The Myth: “Finally, Custom UI in Model-Driven Apps!”

A recurring narrative I’ve seen is that Generative Pages are being celebrated as the first real way to build custom UIs in Model-Driven Apps. But for those of us who’ve been around since the Dynamics CRM days, this isn’t exactly new territory.

We’ve always had the ability to create custom interfaces using HTML WebResources. Whether it was jQuery in the early days or more modern stacks like React + TypeScript + Fluent UI, the platform has long supported advanced UI customization. The only difference? Back then, you had to roll up your sleeves and build it yourself.

🔍 The Reality: Generative Pages Are a New Abstraction, Not a New Capability

Generative Pages are a fantastic addition—don’t get me wrong. They lower the barrier to entry, especially for makers and newcomers who might not be familiar with the extensibility model of Dataverse. But they’re not a replacement for pro-code solutions. They’re a new abstraction layer, not a new frontier.

If you’re looking for true flexibility, performance, and control, custom WebResources still reign supreme. And if you’re wondering how to get started with those, I’ve written extensively on the topic:

Dataverse Web Resources with React, Typescript and FluentUI (_neronotte's way)
Form-based Dataverse Web Resources with React, Typescript and FluentUI - Part 1
Form-based Dataverse Web Resources with React, Typescript and FluentUI - Part 2
Say Goodbye to CRA, Hello to Vite - the last but most important, because the previous articles rely on an NPM template that no longer exists.

These posts walk through everything from scaffolding your project to handling context injection and deploying with PACX. They’re not just tutorials—they’re a testament to the maturity and power of the platform’s extensibility model.

And they were written before the Generative AI era. Now you can also leverage GitHub Copilot capabilities in VS or VS Code to implement the logic, making the gap with Generative Pages even lower.

🧪 WebResources vs PCFs: The Debugging and Testing Advantage

Another point that often gets overlooked in the Generative Pages vs. WebResources vs. PCF debate is the developer experience—especially when it comes to debugging and testing.

Compared to PCFs (PowerApps Component Framework), WebResources are significantly easier to debug. You can run them in the browser, inspect them with standard dev tools, and iterate quickly without the need for complex build pipelines or deployment steps. This makes them ideal for rapid prototyping and iterative development.

PCFs, while powerful, come with a steeper learning curve and a more rigid development lifecycle. Debugging often requires attaching to the browser process, dealing with iframes, and managing a more complex deployment model. For many use cases, especially those that don’t require deep integration with the control lifecycle, WebResources are simply more efficient.

💾 Source Control and DevOps: Still a Win for WebResources

One of the lesser-known advantages of WebResources is how well they integrate with source control and CI/CD pipelines. Thanks to tools like Power Platform CLI and PACX, you can manage your WebResource projects in Git, automate deployments, and maintain a clean, versioned history of your codebase.

This is still a significant advantage over Generative Pages, which—at least for now—lack the same level of DevOps maturity. While Microsoft is making strides in this area, the ability to fully own and manage your codebase remains a key differentiator for WebResources.

🌟 The Real Value Behind Generative Pages

Generative Pages are worth the excitement because they fundamentally shift the accessibility of custom experiences in Model-Driven Apps.

For years, building tailored interfaces meant diving into pro-code solutions like WebResources or PCF—powerful, but often out of reach for makers and business users.

Generative Pages change that equation by introducing an abstraction layer that democratizes UI creation without sacrificing Dataverse integration or solution governance.

They accelerate time-to-value, reduce dependency on specialized front-end skills, and align perfectly with the low-code ethos of Power Platform.

In short, they don’t replace pro-code—they complement it, enabling organizations to deliver functional, data-centric pages faster and with less friction, while still leaving room for deeper customization when needed.

🤔 Final Thoughts

Let’s welcome Generative Pages for what they are: a helpful tool in the toolbox. But let’s also continue to educate and advocate for the powerful capabilities that have been there all along. The Power Platform isn’t just evolving—it’s maturing. And as professionals, it’s our job to guide that evolution with clarity and context.

If you’re serious about building rich, enterprise-grade experiences in Model-Driven Apps, don’t overlook the power of WebResources. They’re not just legacy—they’re battle-tested, flexible, and still incredibly relevant.

Your Dataverse Solutions Deserve Better Builds (Here’s How)

Riccardo Gregori — Sun, 19 Oct 2025 14:22:37 +0000

Based on my personal experience (I have been working on Dynamics CRM / Power Platform since 2009 and have delivered dozens of projects), today a typical middle-sized CRM / Model Driven App project contains:

A data model made of roughly 30 tables.
A few dozen basic Web Resources (images, form JS, command bar JS, theme assets, etc.).
One or more Plugin Packages.
One or more HTML/React Web Resources.
One or more PCF controls.
One or more Power Automate flows (with related Connection References).
One or more Model Driven Apps.
Roles, field security profiles… everything concerning the security model.

This is the typical content of a middle-sized project; obviously there are smaller ones, but also much larger and more complex initiatives, each with its own peculiarities.

Looking at the structure of my typical medium project, over time I have tried to standardize ALM processes, industrializing my delivery approach, with the goal of improving (making more efficient) the way I work and the way the people working with me operate.

🧱 Solutions

This industrialized approach also involves defining the Dataverse solutions that compose the application in a consistent way: I prefer a layered approach where solutions are organized by component type, with a strict and well-defined dependency direction.

1st principle: Each solution contains only and exclusively components that depend on components present in lower-level solutions.

Following the 1st principle, the solutions I typically define are the following:

Layer	Name	Description
1	0100 - WebResources	Contains all project Web Resources (images, form and command bar JS, theme, assets, HTML pages, etc.).
2	0200 - PCF	Contains custom PCF controls implemented for the project.
3	0300 - Data Model	Contains the system data model (tables, columns, forms, views).
4	0400 - Business Logic	Contains Plugin Packages, Steps, Custom APIs, Power Automate flows—everything that is business logic.
5	0500 - Other	Contains apps, sitemaps, security roles(1), and the rest of the solution components.

(1) For roles a specific discussion is needed: if system forms and views depend on roles, then roles go into the Data Model solution; otherwise they go into "Other".

Layering note: the order of the layers is based on import prerequisites (a form may require a Web Resource / PCF already present), not on the functional responsibility flow (UI consuming the data model). Web Resources and PCF controls do not create formal dependencies toward tables/columns until they are attached to forms, so they can be imported earlier.

Naming convention note: Each solution starts with a 4-digit number. The first 2 digits represent the current layer. The second two digits are used when the solution becomes too large and you decide to fragment its content. Example: suppose you have N React Web Resources (which are typically heavier). You might decide to have a separate solution for each one. In that case I would name them:

0100 - WebResources - Base
0101 - WebResources - Home Page
0102 - WebResources - Monitoring Dashboard
0103 - WebResources - Customer Details
…

🔢 Source Versioning

In my projects, both the source code of the custom components I build (Plugins, Web Resources, PCF controls, etc.) and the solutions described earlier—downloaded and unpacked into their minimal components through pac solution sync—are versioned in a Git repository (Azure DevOps / Visual Studio or GitHub, based on client preference).

However, when we download solutions locally to version them, we have a problem: they contain all our customizations, including Web Resources (compiled, in the case of React-based Web Resources) and .nupkg files of our Plugin Packages.

Anyone who has studied ALM theory knows one thing:

2nd principle: The repository must not contain artifacts—only source code.

To avoid storing in the repo what are effectively duplicates of already existing objects (think simple Web Resources) or artifacts (the HTML/JS/CSS of React Web Resources, or plugin .nupkg files), mapping files come to the rescue (we already discussed them in the article "Relative Paths in Solution Mapping Files" and in "When Plugin Packages Break Your Mapping Files (and How to Fix It)").

The rules for composing and incrementing the build version number are described in the "Version Format" paragraph in the Pipeline section.

🧩 And what about PCF?

For the PCF solution the technique I use is slightly different. While in other cases I first create the solution in Dataverse and then obtain a local copy via pac solution clone / pac solution sync, for PCF I:

Create a solution directly locally using pac solution init.
Add the PCF project(s) to the solution as references using pac solution add-reference.
Modify the .cdsproj file adding the PropertyGroup shown below so that I get a Managed solution if I compile in Release mode, and an Unmanaged one if I compile in Debug mode.

<PropertyGroup>
    <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
    <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
    <SolutionFileVersion></SolutionFileVersion>
    <SolutionPackageEnableLocalization>false</SolutionPackageEnableLocalization>
</PropertyGroup>

After that, I just compile the solution in Release mode and push it to Dataverse using pac solution import… and PCF controls are up and running.

🚀 Pipeline

With such an organization of solutions, if we want to manage releases in a deterministic and reproducible way, we should build a build pipeline that performs the following steps:

Define the version number associated with the current build (Build.BuildNumber).
Compile the React Web Resources.
Compile the projects related to plugin DLLs to generate the PluginPackage (.nupkg).
Update the solutions' versions setting them to Build.BuildNumber.
Compile the PCF solution (0200 - PCF) in Release mode.
Compile the remaining Dataverse solutions in Release mode, retrieving:
1. Simple Web Resources from the folder where they reside in the repo.
2. React Web Resources from the folder containing the built output generated in step #2.
3. Plugin packages from the bin\Release subfolder of the corresponding project.

🧮 Version Format

The value used for Build.BuildNumber (or equivalent runner number) must follow the format <major.minor.patch.build>.

The version number of the .nupkg (Plugin Package) is normally not relevant for import: the environment accepts the update as long as existing plugin types/contracts are not broken. However, the version MUST change (major or minor) when one or more plugin classes previously deployed are physically removed; otherwise you risk hitting the following error:

Exception type: System.ServiceModel.FaultException[Microsoft.Xrm.Sdk.OrganizationServiceFault]

Message: Plugin Assemblies import: FAILURE. Error: Plugin: 'NAME OF PLUGIN ASSEMBLY', Version=<0.1.0.0> ... caused an exception.: Existing plug-in types have been removed. Please update major or minor verion of plug-in assembly. ...

🔁 Back to the pipeline

Theoretically implementing such a pipeline seems quite trivial.

In reality, when you try to set it up you hit several problems:

Passing the version number to solutions at compile time (via dotnet build, as we would for any other .NET project) does not work. The version number passed as a parameter is not reflected in the actual solution version. The only way to make the solution actually reflect the current build version is to add a PowerShell script that physically modifies the Solution.xml files, changing the Version node, manually or through the pac solution version command.
Mapping files do not work with Plugin Packages. Or rather… they work during sync, but not during build. You need something that manually copies the .nupkg files generated by compiling the plugin DLLs into the solution folder before building the solution itself.
The .nupkg files generated by the DLL build, moreover, have a different name than expected by the Dataverse solutions. So you also need a rename step "in the middle," before or after the copy.

' Package generated by the DLL project build
Greg.Plugins.1.0.0.nupkg

' "Expected" name by the Dataverse solution
nn_Greg.Plugins.nupkg

I tried N different ways to build a general purpose pipeline that performed all necessary steps, overcoming the problems listed above, but honestly none of the solutions I arrived at ever fully satisfied me.

Too many variables inside the pipeline code.

Too many steps to manually modify project by project.

…until…

🚨 Betim to the rescue 🚨

My friend Betim Beja suggested I try using his project templates, completely open source and available on GitHub.

For me, a turning point.

His AlbanianXrm.CDSProj.Sdk is an SDK-style Visual Studio project template that can be used to replace the standard definition of .cdsproj projects automatically generated by pac solution clone / pac solution sync.

Compared to the "original" Dataverse template, it drastically simplifies managing all the issues I listed above.

⁉️ How to use it

After creating your solution inside Dataverse (manually, or via pacx solution create):

Step 1. Clone the solution locally using pac solution clone.

Step 2. Open the file solutionname.cdsproj, which should look similar to the following:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <PowerAppsTargetsPath>$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\PowerApps</PowerAppsTargetsPath>
  </PropertyGroup>

  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
  <Import Project="$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.props" Condition="Exists('$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.props')" />

  <PropertyGroup>
    <ProjectGuid>5aa1879b-b4a3-4734-bcad-d964d642cdff</ProjectGuid>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
    <!--Remove TargetFramework when this is available in 16.1-->
    <TargetFramework>net462</TargetFramework>
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
    <SolutionRootPath>src</SolutionRootPath>
  </PropertyGroup>

  <!-- 
    Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both)
    Solution Localization Control, if you want to enabled localization of your solution, un-comment SolutionPackageEnableLocalization and set the value to true. - Requires use of -loc flag on Solution Clone or Sync
  -->
  <!--
  <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
    <SolutionPackageEnableLocalization>false</SolutionPackageEnableLocalization>
  </PropertyGroup>
  -->

  <ItemGroup>
    <PackageReference Include="Microsoft.PowerApps.MSBuild.Solution" Version="1.*" />
    <PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
  </ItemGroup>

  <ItemGroup>
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\.gitignore" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\bin\**" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\obj\**" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.cdsproj" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.cdsproj.user" />
    <ExcludeDirectories Include="$(MSBuildThisFileDirectory)\*.sln" />
  </ItemGroup>

  <ItemGroup>
    <None Include="$(MSBuildThisFileDirectory)\**" Exclude="@(ExcludeDirectories)" />
    <Content Include="$(SolutionPackageZipFilePath)">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

  <Import Project="$(MSBuildToolsPath)\Microsoft.Common.targets" />
  <Import Project="$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.targets" Condition="Exists('$(PowerAppsTargetsPath)\Microsoft.PowerApps.VisualStudio.Solution.targets')" />

</Project>

Step 3. Remove all its content and simply replace it with the following:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
        <SolutionFileVersion>$(FileVersion)</SolutionFileVersion>
    </PropertyGroup>
</Project>

And you're done.

The SolutionFileVersion node performs the magic of automatically managing the solution version based on the value passed via dotnet build /p:FileVersion=1.0.1.1. No manual edits required.

🕸️ And the web resources?

If the solution you are managing is the one that contains the web resources, add the mapping file:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageMapFilePath>$(MSBuildThisFileDirectory)map.build.xml</SolutionPackageMapFilePath>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
    </PropertyGroup>
</Project>

Which, in my case, looks like this (nn is the publisher prefix):

<?xml version="1.0" encoding="utf-8"?>
<Mapping>
    <Folder map="WebResources\nn_" to="..\..\..\..\..\..\src\WebResources\nn_" />
</Mapping>

📦 Nice… but what about the `.nupkg` files?

Betim thought of that too. If you want to avoid the whole annoying process of:

Manually compiling plugin DLLs to generate .nupkg files.
Renaming them one by one into the name "expected" by the Dataverse solution.
Moving them one by one into the appropriate folder where dotnet build will look when rebuilding the solution (managed or unmanaged).

Just add an ItemGroup like the following to the project:

    <ItemGroup>
        <ProjectReference Include="..\..\src\Greg.Plugins\Greg.Plugins.csproj" />
    </ItemGroup>

Referencing the project created via pac plugin init, and that's it. The project itself, during build, will do the dirty work for you.

Below is a complete file example, where I also add a few extra parameters at my discretion:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="AlbanianXrm.CDSProj.Sdk/1.0.5">
    <PropertyGroup>
        <SolutionPackageMapFilePath>$(MSBuildThisFileDirectory)map.build.xml</SolutionPackageMapFilePath>
        <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
        <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
        <SolutionFileVersion>$(FileVersion)</SolutionFileVersion>

        <!-- other properties added to manage logging and zip file generation -->
        <SolutionPackageEnableLocalization>true</SolutionPackageEnableLocalization>
        <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Debug'">Verbose</SolutionPackageErrorLevel>
        <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Release'">Info</SolutionPackageErrorLevel>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Debug'">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_unmanaged.zip</SolutionPackageZipFilePath>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Release'">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_managed.zip</SolutionPackageZipFilePath>
        <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' == ''">$(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion).zip</SolutionPackageZipFilePath>
    </PropertyGroup>

    <ItemGroup>
        <ProjectReference Include="..\..\src\Greg.Plugins\Greg.Plugins.csproj" />
    </ItemGroup>
</Project>

✅ Conclusions

In the end the problems that make us waste time in Model Driven projects are always the same: version numbers that communicate nothing, mapping breaking with Plugin Packages, manual rename of .nupkg files, uneven handling between PCF and Web Resources, PowerShell scripts patching Solution.xml. All repetitive work that adds no value and we'd rather forget.

The SDK template AlbanianXrm.CDSProj.Sdk does most of the heavy lifting: no scripts to force versioning, no manual copy/rename of packages, no “magical” builds different project by project. You reference the plugin project and it prepares the .nupkg as needed; you pass FileVersion and the solution aligns; you build and import. Done.

The Power Platform / Dynamics CRM community is, once again, that place where someone has already suffered before you and decided to share the cure. If today you are still manually renaming files or fixing version numbers at the end of the build, take a test solution, apply the template and measure how much time you save. After a few rounds it will be hard to go back.

A special thanks to Betim Beja for providing the AlbanianXrm.CDSProj.Sdk accelerator: it turned several recurring nuisances into details we simply no longer have to manage.

If you feel like it, let me know what you still miss to make your ALM truly “boring” (and therefore healthy): that is usually where it’s worth investing in the next improvement.

When Plugin Packages Break Your Mapping Files (And How to Fix It)

Riccardo Gregori — Sun, 05 Oct 2025 09:34:25 +0000

🥱 TL;DR

FileToFile mappings for plugin package .nupkg files in Dataverse Solution Packager repeatedly throw Error: Value cannot be null. Parameter name: key during pac solution sync. Everything else (FileToPath, WebResources, metadata) works.
Workaround:

Add an MSBuild target that creates a stable, versionless ava_Plugins.nupkg alongside the versioned Plugins.x.y.z.nupkg.
Maintain two mapping files—one without the plugin package line for sync, one (optional) with it for future pack scenarios.
Use a short PowerShell script to run sync, then clean or regenerate the stable package as needed.

Result: deterministic builds, clean repository, and an isolated workaround until an upstream fix lands.

🚀 1. Introduction

When we work on Dataverse solutions we routinely leverage the Solution Packager mapping file to keep the repository clean and to steer build artifacts. Everything behaves as expected for WebResources and other assets—until we introduce a FileToFile mapping for a Plugin Package (pluginpackages/.../package/*.nupkg). Every time we try that, the same failure appears:

Error: Value cannot be null.
Parameter name: key

This post documents the persistent problem, the investigation path, the changes made to the plugin project (Plugins.csproj in these examples), and the pragmatic workaround we apply each time: maintaining two mapping files plus a tiny automation script.

🤷🏻 Name Mismatch Deep Dive (Why a Stable Copy Is Mandatory)

Here's where things get frustrating. Even before we hit the cryptic null-key bug, there's a sneaky naming mismatch that'll drive you crazy if you don't catch it early.

Picture this: you build your plugin project and get Plugins.1.0.0.nupkg. Perfect! But when you extract a Dataverse solution, the same logical package shows up as ava_Plugins.nupkg. Wait, what? 🤔

Source	Default Naming Rule	Example Output	Changes When	Stable?	Used By
Plugin project build (`dotnet pack` implicit/explicit)	`<PackageId>` + `.` + `<Version>`	`Plugins.1.0.0.nupkg` → `Plugins.1.0.1.nupkg`	Every version bump	No	NuGet feeds, artifact stores, human traceability
Dataverse solution export (`pluginpackages` node)	Publisher prefix + logical package name	`ava_Plugins.nupkg`	Rare (only if solution structure/prefix changes)	Yes	Solution Packager re-import, ALM pipelines

This mismatch will bite you in multiple ways:

FileToFile in map.xml demands exact filenames—no wildcards, no "close enough."
Every time you bump versions (1.0.0 → 1.0.1), you'd have to update your mapping file manually. In a fast-moving project, that's a recipe for "oops, forgot to update the map again."
Dataverse doesn't care about your semantic versioning—it wants that stable ava_Plugins.nupkg name, period.
Even if Microsoft fixes the null-key bug tomorrow, you still need that predictable filename or you're back to manual map editing hell.

Our approach: create a "stable twin" during the build. The MSBuild target spots any Plugins.*.nupkg and copies it to ava_Plugins.nupkg (keeping both, or deleting the versioned one if you prefer less clutter). Now your mapping file can reference a filename that never changes, and your versioned packages can still live their best life in artifact repositories.

We tried other approaches first:

Just rename the primary package → Nope, then you lose version traceability when you push to feeds.
Update the map file every release → High maintenance nightmare, especially when you're shipping weekly.
Symlinks or hardlinks → Sounds clever until your CI agent doesn't have permission or you hit cross-platform issues.
Manual rename after sync → Fragile, easy to forget, and definitely not CI-friendly.

The copy approach handles the edge cases too:

Multiple versioned packages lying around? It grabs them all, picks one to copy, optionally cleans up the rest.
First build ever? Stable file magically appears.
Rebuilding the same version? Only copies if the stable file is missing (keeps builds fast).

Bottom line: this isn't some fancy optimization—it's the foundation that makes everything else possible. Without that stable filename, you're constantly fighting the tooling instead of building features.

To address for the Name mismatch issue, we could simply add the following snippet to our Plugins.csproj file. The snippet simply renames the generated package (Plugins.1.0.0.nupkg) as expected by the Dataverse solution project (ava_Plugins.nupkg).

<!-- Post-build: create stable (publisher-prefixed, versionless) plugin package file
   Needed so Solution Packager mapping (<FileToFile ...> in map.xml) can always
   point to ava_Plugins.nupkg regardless of version increments.
   The actual versioned file is produced by the PowerApps plugin build targets.
   We derive the expected versioned filename from $(FileVersion). -->
<PropertyGroup>
    <!-- PowerApps plugins output packages to bin\Configuration\ not bin\Configuration\TargetFramework\ -->
    <PluginPackageOutputDir>$(ProjectDir)bin\$(Configuration)\</PluginPackageOutputDir>
    <!-- Stable filename consumed by map.xml mapping (internal solution file name) -->
    <StablePluginPackage>$(PluginPackageOutputDir)ava_Plugins.nupkg</StablePluginPackage>
    <!-- Toggle: set to false to keep the versioned nupkg alongside the stable one -->
    <DeleteVersionedOnCopy>true</DeleteVersionedOnCopy>
</PropertyGroup>

<Target Name="CopyStablePluginPackage" AfterTargets="Pack" Condition="'$(DesignTimeBuild)' != 'true'">
    <Message Text="[CopyStablePluginPackage] Looking for packages in: $(PluginPackageOutputDir)" Importance="High" />

    <!-- Discover all versioned packages (exclude stable) -->
    <ItemGroup>
        <VersionedPackages Include="$(PluginPackageOutputDir)Plugins.*.nupkg" Exclude="$(StablePluginPackage)" />
    </ItemGroup>

    <Message Text="[CopyStablePluginPackage] Found versioned packages: @(VersionedPackages)" Importance="High" />

    <!-- If we have at least one versioned package, pick the first one -->
    <ItemGroup Condition="'@(VersionedPackages)' != ''">
        <CandidatePackage Include="@(VersionedPackages)" />
    </ItemGroup>

    <!-- Copy first candidate to stable -->
    <Copy SourceFiles="@(CandidatePackage)" DestinationFiles="$(StablePluginPackage)" SkipUnchangedFiles="true" Condition="'@(CandidatePackage)' != ''" />
    <Message Text="[CopyStablePluginPackage] Created stable package from: @(CandidatePackage)" Importance="High" Condition="Exists('$(StablePluginPackage)') and '@(CandidatePackage)' != ''" />
    <Warning Text="[CopyStablePluginPackage] No versioned plugin package found in $(PluginPackageOutputDir)" Condition="'@(VersionedPackages)' == ''" />

    <!-- Delete versioned packages if toggle enabled -->
    <Delete Files="@(VersionedPackages)" Condition="'@(VersionedPackages)' != '' and '$(DeleteVersionedOnCopy)' == 'true'" />
    <Message Text="[CopyStablePluginPackage] Deleted versioned packages: @(VersionedPackages)" Importance="Low" Condition="'@(VersionedPackages)' != '' and '$(DeleteVersionedOnCopy)' == 'true'" />
</Target>

📂 2. Why Mapping Files Matter

We have already discussed this topic here.
Mapping files give us two high‑value benefits:

Keep build artifacts (generated or compiled outputs) out of source control by redirecting extracted solution components to curated locations under src/.
Let the .NET build (and related tooling) know where to find externally‑mapped artifacts when we later repack or rebuild the solution (deterministic layout).

For WebResources and most XML/JSON metadata, FileToPath patterns work flawlessly. The friction appears specifically with Plugin Package .nupkg binaries when using FileToFile.

🎯 3. The Issue

Here's what we're trying to solve: we want plugin packages out of source control but available for builds. The FileToFile mapping should accomplish two things:

During pac solution sync: Skip creating the plugin package locally (since we're pointing it to an external file)
During solution builds: Let the compiler grab the plugin package from our project's build output instead of the default location

The ideal workflow: sync extracts everything except the plugin package (which stays out of source control), then when you build the solution, it finds the plugin package in src/Plugins/bin/Debug/ava_Plugins.nupkg where our MSBuild target puts it. Clean repository, deterministic builds, everyone's happy.

So you add a FileToFile mapping to your map.xml:

<FileToFile map="pluginpackages\ava_Plugins\package\ava_Plugins.nupkg"
            to="..\\..\\..\\..\\..\\src\\Plugins\\bin\\Debug\\ava_Plugins.nupkg" />

Make sure your stable package exists (more on that later), run pac solution sync --map .\map.xml -loc, and... boom:

Error: Value cannot be null. Parameter name: key

Remove that one line? Works perfectly. Add it back? Instant failure. It's like the tooling has a personal vendetta against plugin package remapping.

🧪 4. Analysis of the Failure

Observations:

The error fires only when a FileToFile directive targets the Plugin Package .nupkg.
The same mapping file is perfectly accepted later by MSBuild / pack operations (the build does not care about the mapping; it simply uses the stable binary).
All relative path depth corrections (2, 5, 6 ..) did not resolve the null key error.
Using FileToPath wildcards for pluginpackages (pluginpackages\**) avoided the exception but did not relocate the binary (Solution Packager still emitted the file into its default folder).

Likely internal cause: Solution Packager's plugin package handling expects the physical file to remain in its canonical relative location and does not fully support remapping its binary via the map dictionary used during unpack/localization. When the dictionary lookup for the remapped external target occurs, the expected key is absent → null.

🔧 5. The Practical Workaround: Dual Mapping Files

Because the FileToFile mapping for the plugin package breaks pac solution sync, but is still desirable for a future pack/build context, we maintain two mapping files:

Purpose	File	Contains Plugin `FileToFile`?
Sync from Dataverse → FS	`map.sync.xml`	No
Build / (Optional future pack)	`map.build.xml`	Yes

Workflow:

Run sync using map.sync.xml (no plugin mapping → no error).
Manually (or via script) remove the extracted nupkg under solutions/.../pluginpackages/.../package/.
Build solution; the csproj target recreates stable ava_Plugins.nupkg.
Use map.build.xml only if you later need a pack that references the external stable file (until the PAC CLI issue is fixed, avoid using it for sync).

📝 Solution Project Configuration for Build Mapping

To enable the solution project to use the map.build.xml file during builds, add the following configuration to your master.cdsproj file:

<PropertyGroup>
<SolutionPackageMapFilePath>$(MSBuildThisFileDirectory)map.build.xml</SolutionPackageMapFilePath>
  <SolutionPackageType Condition="'$(Configuration)' == 'Debug'">Unmanaged</SolutionPackageType>
  <SolutionPackageType Condition="'$(Configuration)' == 'Release'">Managed</SolutionPackageType>
  <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Debug'">Verbose</SolutionPackageErrorLevel>
  <SolutionPackageErrorLevel Condition="'$(Configuration)' == 'Release'">Info</SolutionPackageErrorLevel>
  <SolutionPackageEnableLocalization>true</SolutionPackageEnableLocalization>
  <!-- The value for this property has to be passed during runtime when you run dotnet build -->
  <SolutionFileVersion></SolutionFileVersion>
  <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Debug'">
    $(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_unmanaged.zip</SolutionPackageZipFilePath>
  <SolutionPackageZipFilePath Condition="'$(SolutionFileVersion)' != '' AND '$(Configuration)' == 'Release'">
    $(OutputPath)$(MSBuildProjectName)_v$(SolutionFileVersion)_managed.zip</SolutionPackageZipFilePath>
</PropertyGroup>

This configuration:

Points the solution build to use map.build.xml (which includes the plugin package mapping)
Sets up different package types and error levels for Debug vs Release builds
Enables localization support
Configures versioned output file naming for solution packages

With this setup, when you build the solution project (dotnet build or MSBuild), it will properly locate the plugin package via the FileToFile mapping in map.build.xml.

🤖 6. Automation Script (Sync + Cleanup)

To be sure to always perform step 1 and 2 described above, I tend to use a special-purpose powershell script.

sync.ps1 (proposed):

param(
  [string]$SolutionFolder = "."
)

$SyncMap = "$SolutionFolder/map.sync.xml"

Write-Host "[Sync] Using map: $SyncMap"
pac solution sync --map $SyncMap -loc || throw "Solution sync failed"

# Find and remove all .nupkg files under the solution folder
$nupkgFiles = Get-ChildItem -Path $SolutionFolder -Recurse -Filter "*.nupkg" -File
if ($nupkgFiles.Count -gt 0) {
  Write-Host "[Cleanup] Found $($nupkgFiles.Count) .nupkg file(s) to remove:"
  foreach ($file in $nupkgFiles) {
    Write-Host "  - $($file.FullName)"
    Remove-Item $file.FullName -Force
  }
  Write-Host "[Cleanup] All .nupkg files removed from solution folder."
} else {
  Write-Host "[Cleanup] No .nupkg files found in solution folder (already clean)."
}

⚖️ 8. Pros & Cons of Dual-Map Strategy

Pros

Unblocks daily sync workflow immediately.
Keeps repository clean of large binary artifacts.
Build remains deterministic (stable filename always present).

Cons

Two mapping files add cognitive overhead.
Extra cleanup step (script) until the underlying issue is fixed.
Risk of accidental use of the build map during sync (document clearly in README / contributor guide).

⚠️ Disclaimer

If/when the upstream behavior changes, this post can be revisited to retire the workaround.

Feel free to adapt the script & structure to your own Dataverse ALM conventions.

Forem: Riccardo Gregori

Power Pages SPA Learning By Doing - Keep it clean

🤔 The issue - Stale files generated by chunking strategy

💡 How to fix it?

📌 Step A. Apply deterministic names on chunks

1. Disable hashing entirely (simplest)

2. Use a fixed/stable hash (content-based, but stable)

3. Pin your manual chunks (most robust for ALM)

4. Disable code splitting entirely (nuclear option)

Recommended approach for Power Pages

🧹 B. Good, but now how I get rid of the old files?

🖖🏼 C. Let's finish by hand

🎯 Final considerations

Simple, but yet rock hard, truth.

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

Greg.KeySub – The Ultimate Revenge Against the Italian Keyboard

Introducing: Greg.KeySub

Why You Should Install It Right Now

Install it, try it, love it ❤️

Modern Power App development takes a lot of... SPACE.

🧠 The Paradigm Shift: Why We Don’t Argue UI Anymore

🧱 The Problem: A Dozen PCFs/WebResources = Disk Space Meltdown

🧩 The Hidden Gem: NPM Workspaces

🤔 How Does It Works?

🗂️ A Practical Folder Structure for Power Platform Projects

📉 How Much Space Do You Actually Save?

🪄 Conclusions

Automatically Refresh Forms After Status Changes in Model Driven Apps

How to: Fix WebResources Layout in Dataverse Dashboards

🤔 The problem

💡 The solution

😎 The result

Model Driven App: disable "Open in Excel Online" button

🤔 The issue

😖 Failed fix tentatives

👍🏻 How to do it

Dataverse MCP Server configuration failed...

💵 Dataverse Exchange Rates 101 💵

🔹 When Exchange Rate IS Applied

🔹 When Exchange Rate is NOT Applied

Generative Pages: The Right Hype, for the Wrong Reason

🦄 The Myth: “Finally, Custom UI in Model-Driven Apps!”

🔍 The Reality: Generative Pages Are a New Abstraction, Not a New Capability

🧪 WebResources vs PCFs: The Debugging and Testing Advantage

💾 Source Control and DevOps: Still a Win for WebResources

🌟 The Real Value Behind Generative Pages

🤔 Final Thoughts

Your Dataverse Solutions Deserve Better Builds (Here’s How)

🧱 Solutions

🔢 Source Versioning

🧩 And what about PCF?

🚀 Pipeline

🧮 Version Format

🔁 Back to the pipeline

🚨 Betim to the rescue 🚨

⁉️ How to use it

🕸️ And the web resources?

📦 Nice… but what about the .nupkg files?

✅ Conclusions

When Plugin Packages Break Your Mapping Files (And How to Fix It)

🥱 TL;DR

🚀 1. Introduction

🤷🏻 Name Mismatch Deep Dive (Why a Stable Copy Is Mandatory)

📂 2. Why Mapping Files Matter

🎯 3. The Issue

🧪 4. Analysis of the Failure

🔧 5. The Practical Workaround: Dual Mapping Files

📝 Solution Project Configuration for Build Mapping

🤖 6. Automation Script (Sync + Cleanup)

⚖️ 8. Pros & Cons of Dual-Map Strategy

Pros

Cons

⚠️ Disclaimer

📦 Nice… but what about the `.nupkg` files?