Integrations can be either inbound or outbound. This article will focus on outbound integration—specifically, using a Managed Identity to allow Power Platform (Dataverse) plugins to securely call external Azure resources.

Overall Goal

The primary purpose of configuring a Managed Identity (MI) is so that Microsoft Entra ID will trust the calling plugin assembly. This allows your custom Dataverse code to securely authenticate against external Azure services without embedding credentials.

Step-by-Step Implementation

• Certificate: Generate the .pfx file containing the key pair.
• Certificate: Import the .pfx into the Windows certificate store.
• Azure: Create a user-assigned managed identity.
• Dataverse: Create an application user and link it to the managed identity record.
• Dataverse: Assign the required security roles.
• Development: Build the plugin .dll.
• Security: Sign the assembly using the generated certificate.
• Deployment: Upload the signed assembly to Dataverse.
• Configuration: Link the assembly with the managed identity in Dataverse.
• Azure: Add federated credentials and role assignments with the Azure managed identity.
• Validation: Test the integration.

Generate a Self-Signed Certificate

Your certificate must contain a key pair (both private and public keys) to sign the assembly. Below is a PowerShell example to generate one.

$kuCodeSigning = "1.3.6.1.5.5.7.3.3";

$cert = New-SelfSignedCertificate `
  -Type "CodeSigningCert" `
  -KeyExportPolicy "Exportable" `
  -Subject "VivoAirManagedIdentityPlugin" `
  -KeyUsageProperty @("Sign") `
  -KeyUsage @("DigitalSignature") `
  -TextExtension @("2.5.29.37={text}$($kuCodeSigning)", "2.5.29.19={text}false") `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -KeyLength 2048 `
  -NotAfter ([DateTime]::Now.AddYears(1)) `
  -Provider "Microsoft Software Key Storage Provider";

$emptyPassword = [System.Security.SecureString]::new()

Export-PfxCertificate `
  -Cert "Cert:\CurrentUser\My\$($cert.Thumbprint)" `
  -FilePath "$env:TEMP\VivoAirManagedIdentityPlugin.pfx" `
  -Password $emptyPassword;

The ku in kuCodeSigning stands for key usage. The example provided in standard Microsoft documentation is typically for secure email signage, which is not designed for signing plugin assemblies. The OID 1.3.6.1.5.5.7.3.3 explicitly ensures it is valid for code signing.

You need to register the keys of the generated .pfx file within the Windows certificate storage. Ensure it is placed in both the Personal and Trusted Root Certification Authorities nodes for successful signing.

Signing Tool

Use the Windows SDK SignTool to apply the certificate to your assembly.

Create a Managed Identity Record in Dataverse

You can establish this link by creating an application user in the Power Platform admin center.

Calling Managed Identity for Bear Token

        public string GetToken(List<string> scopes)
        {
            return _managedIdentityService.AcquireToken(scopes);
        }

Add Federated Security in Azure

When configuring the federated credentials in Azure, the subject string is used to pinpoint the intended caller plugin assembly. Note that the expected subject format has changed from v1 to v2.

Managed Identity Basics

There are two types of Managed Identities: System-Assigned and User-Assigned. For Power Platform plugins connecting to Azure, we create and utilize a User-Assigned Managed Identity.

References

• Set up managed identity for Power Platform Plugins
• Power Platform Plugin Package – Managed identity
• Set up Power Platform managed identity for Dataverse plug-ins or plug-in packages
• SignTool.exe (Sign Tool)
• New-SelfSignedCertificate

Future Posts

• Managed Identity with Plugin Packages
• Managed Identity with vNet and apim

We need CI/CD and ALM in Power Platform to move from ad‑hoc manual exports/imports to predictable, governed delivery.

Key Pillars

Development Experience

• Plugin Registration
• Codegen
• Unpack Solutions
• Pack Solutions

Strategies

Solution Segregation

Option 1: Split by Features But you will still need a core solution for shared components, and if the core solution becomes too big, you need to split it.

Option 2: Split by Components Customization, Plugin, Workflows and etc.

Layering

The final product is like a cake and each solution is like a layer of the cakse. The solution importing sequence is important because it dictates if and how solution layer are stacked and which overwrite which.

CICD Experience

• Deployment targeting - you can target multiple systems, so called fan out. You can keep the deployment mapping configration in the json.
• PR merge gate with Pre-validation and code review.
• Deployment gate - approver before deployment goes ahead
• Deploy - ADO stages and steps and tools.
• Post Deploy - master data import

Evolution

Manually export solutions in a folder

Back in the bad old days, the packaging are handled manually, meaning the dev team will manually export solutions and put them in a folder in the source repository. Later the CICD pipeline will deploy the solutions from the repo. Optionally, you can provide CICD pipeline with powershell scripts to unpack the zip solution and inject the built plugin dlls and re-package.

Code Based Package

We moved away from committing exported solution .zip files. Instead we use PowerShell with the pac CLI to unpack solutions and commit only the unpacked XML (solution definition) to source control. This gives us:

• Meaningful diffs (component level instead of opaque binaries)
• Better traceability (who changed which attribute/artifact)
• Easier observability and code review

Discipline is critical. The unpacked solution definition in git must always mirror the originating environment. When drift appears, developers are tempted to hand‑edit XML to “force” a change into the next environment—slow, brittle, and error‑prone.

Repository & branching: all squads contribute to the same repository and share a single release/trunk branch (with short‑lived feature branches). We previously experimented with letting squads keep divergent copies of the same solution for “parallel development” and then hand‑merge XML. Outcome: frequent pipeline failures, sprawling merge conflicts across many XML files, and elongated release cycles.

Lessons learned:

1. Don’t manually merge unpacked solution XML. Treat the environment as source of truth; always re‑export/unpack/overwrite instead of editing.
2. Maintain one authoritative branch lineage per solution; avoid long‑running parallel variants.
3. Automate sync validation (pre‑PR or pipeline) to catch drift early.
4. Flow changes forward only (dev → test → prod). Avoid reverse edits by hacking XML.
5. Make pack/unpack scripts idempotent and run them locally and in CI to eliminate divergence.

Core principle: no code‑level merging of solution definitions; solution evolution moves one way toward higher environments.

PPDO

Power Platform Devops is community initiated toolkit which helps with packing, unpacking, codegen, configuration data export and other packing related tasks.

ALM accelerator

ALM Accelerator for Power Platform is microsoft initiated toolkit which helps with packing, unpacking, deployment mapping, pipeline yaml templates and etc.

Power Platform native git integration

Git integration in Power Platform is the Power Platform native support for solution sync and deployment.

// Does not work
ClearCollect(
    colEmployeesGrouped,
    ForAll(
        Distinct(colEmployees, Department),
        With(
            {
                currentDept: ThisRecord.Value,
                matchingRecords: Filter(colEmployees, Department = ThisRecord.Department)
            },
            {
                currentDeptTest: currentDept,
                matchingRecordsTemp: matchingRecords,
                matchingRecordsCount: CountRows(matchingRecords)
             }
        )
    )
);

// Works
ClearCollect(
    colEmployeesGrouped,
    ForAll(
        Distinct(colEmployees, Department),
        With(
            {
                currentDept: ThisRecord.Value
            },
            {
                Department: First(Filter(colEmployees, Department = currentDept)).Department,
                EmployeeNames: Concat(Filter(colEmployees, Department = currentDept), FullName, "; "),
                JobTitles: Concat(Filter(colEmployees, Department = currentDept), JobTitle, "; ")
             }
        )
    )
);

The top code snippet doesn’t work is because ThisRecord.Department doesn’t exist. It will not throw any errors but you will get empty collection rather than expected data.

The problematic code

Filter(colEmployees, Department = ThisRecord.Department)

To fix it, use ThisRecord.Value instead.

Filter(colEmployees, Department = ThisRecord.Value)

So, the takeaway from this is when looping with ForAll, the current record context is super important, i.e. This Record.

ThisRecord example

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value,
                matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = ThisRecord.Value)
            },
            {
                CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
             }
        )
    )
);

The value of ThisRecord changes depend on the scope.

currentOrigin: ThisRecord.Value 

The scope of ThisRecord is Distinct(colCaseParties, CasePartyOriginCombined)

matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = ThisRecord.Value)

The scope of ThisRecord is colCaseParties

Nested With

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value,
                matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)
            },
            {
                CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
             }
        )
    )
);

The above code will not work because of currentOrigin is not recognized inside Filter(colCaseParties, CasePartyOriginCombined = currentOrigin).

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: ThisRecord.Value
            },
            With(
                {
                    matchingRecords: Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)
                },
                {
                    CasePartyOriginCombined: First(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin)).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(Filter(colCaseParties, CasePartyOriginCombined = currentOrigin), CasePartyLawyerName, "; ")
                }
            )
        )
    )
);

The above code works

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined),
        With(
            {
                currentOrigin: Value,
                matchingRecords: Filter(colCaseParties, Value = ThisRecord.CasePartyOriginCombined)
            },

                {
                    CasePartyOriginCombined: First(matchingRecords).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(matchingRecords, CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(matchingRecords, CasePartyLawyerName, "; ")
                }
            
        )
    )
);

Works

ClearCollect(
    colPartiesGrouped,
    ForAll(
        Distinct(colCaseParties, CasePartyOriginCombined) As DistinctCaseParties,
        With(
            {
                currentOrigin: DistinctCaseParties[@Value],
                matchingRecords: Filter(colCaseParties, ThisRecord.CasePartyOriginCombined = DistinctCaseParties[@Value])
            },

                {
                    CasePartyOriginCombined: First(matchingRecords).CasePartyNameCombined,
                    CasePartyRoleNames: Concat(matchingRecords, CasePartyRoleName, "; "),
                    CasePartyLawyerNames: Concat(matchingRecords, CasePartyLawyerName, "; ")
                }
            
        )
    )
);

Works with a disambiguation operator.

Record scope is for each record of a loop function like Filter.

Value is a special field for single columns data table sources.

ThisRecord symbol is for the most immidiate data context.

References

Debugging with local testing harness

npm start or npm start watch

You can debug the PCF code component locally but the problem is it will not load the real data therefore you cannot test it with real data.

Debugging after deployment

After deploy, you can use browser’s developer tools for debugging.

Debugging without deployment

It definitely makes the dev/test feedback loop a lot faster with the benefit of testing it with real data.

Requestly

Fiddler didn’t work for me either. My browser kept saying there was a suspicious network activity when Fiddler was turned on.

So, I tried the other method (Requestly) based on the following msdoc articles - Debug code components - Power Apps

Just at couple of things to note: You need to build your PCF control in production mode in order to get the bundle.js as build output I am using Requestly Chrome add-on for redirect network traffic to my local PCF component bundle.js. The standalone Requestly app may also work but I struggled a little bit and gave up.

References

• https://learn.microsoft.com/en-us/power-apps/developer/component-framework/debugging-custom-controls#using-requestly

Okay, here’s a revised and enriched version of your blog post draft, incorporating details from the Microsoft documentation while maintaining your personal experience and perspective.

Debugging Your Power Apps PCF Controls: From Local Harness to Real Data

Developing Power Apps Component Framework (PCF) controls unlocks powerful UI customizations, but debugging them effectively can sometimes feel tricky. Fortunately, we have several methods available, ranging from quick local checks to debugging against live Dataverse data without constant redeployments. Let’s explore the main approaches.

1. The Local Test Harness (npm start watch)

When you first start building your component logic, the quickest way to see visual changes is using the local test harness. Running npm start or npm start watch in your project directory builds your component and pops it open in a local web page.

• Pros:
  • Fast Feedback Loop: Changes to your index.ts, imported modules, CSS, or resource files trigger an automatic reload in the browser. Great for rapid UI tweaks and basic logic testing.
  • Form Factor Testing: Easily switch between Web, Tablet, and Phone form factors to test responsiveness.
  • Basic Input Simulation: Allows you to provide mock data for properties defined in your manifest. For datasets, you can even load data from a CSV file.
• Cons:
  • No Real Data Context: This is the biggest limitation. The harness runs entirely locally. You cannot interact with actual Dataverse data.
  • Limited API Support: Features like context.webAPI, dataset paging, sorting, filtering, complex lookups/choices, or navigation APIs won’t work. They’ll typically throw errors because the harness doesn’t provide the necessary Power Apps runtime context.
  • Property Updates: The updatedProperties array in updateView isn’t populated correctly when you change inputs in the harness.

Verdict: Excellent for initial development and UI layout, but insufficient for testing logic that interacts with Dataverse.

2. Browser Developer Tools (Your Best Friend Everywhere)

No matter which debugging method you use, your browser’s built-in developer tools (F12 or Ctrl+Shift+I) are essential.

• Key Uses:
  • Inspecting the DOM: Use the ‘Elements’ tab to see the HTML structure your component generates and debug CSS styling issues.
  • Debugging JavaScript: Use the ‘Sources’ tab. Thanks to source maps (generated during development builds via webpack), you can usually find your original TypeScript (.ts) file (often under webpack://), set breakpoints directly in your TS code, step through execution, and inspect variable values.
  • Console: Check for errors and log output using console.log().
  • Network: Analyze API calls (though less relevant for the local harness).
• Tip: In Power Apps Studio, the F12 key might be mapped to something else. Use Ctrl+Shift+I to reliably open the developer tools.

3. Debugging Against Real Data Without Constant Redeployment (The Redirect Method)

This is where things get powerful. You need to test your component with real data and interact with Dataverse APIs, but constantly rebuilding, deploying (pac pcf push), and publishing after every small code change is incredibly slow.

The solution is to deploy your component once to your Dataverse environment, and then use a tool like Fiddler or Requestly to intercept the browser’s request for your component’s code and redirect it to your local machine where you’re running npm start watch.

• The Concept:
  1. Deploy Once: Build and deploy your PCF control to your target Dataverse environment. The Microsoft documentation recommends deploying a production build (PcfBuildMode set to production in .pcfproj or using npm run build -- --buildMode production before pac pcf push). This ensures the component structure matches what the platform expects and avoids potential size limits of development builds.
  2. Run Locally: Start your local development server using npm start watch. This continuously rebuilds your component locally as you make changes.
  3. Intercept & Redirect: Use Fiddler or Requestly to tell your browser: “When you try to load the bundle.js (and related CSS/HTML) for this specific PCF control from Dataverse, load it from my local development server instead.”
  4. Debug: Open Power Apps (model-driven or canvas) where your component is configured. Your browser now loads the code directly from your local machine. Set breakpoints in your TS code using the browser dev tools, interact with your app, and debug against real data! Make code changes, save, let npm start watch rebuild, refresh the Power Apps browser page (a hard refresh Ctrl+Shift+R might be needed initially), and test the new code instantly.

• Tools for Redirection:

  • Fiddler: A powerful web debugging proxy. The MS docs detail setting up its AutoResponder feature with REGEX rules to match requests for your component’s files (bundle.js, CSS, etc.) and map them to your local output folder (e.g., YourProject\out\controls\YourControlName).
    • My Experience: As noted in my draft, I personally ran into issues where my browser flagged Fiddler’s HTTPS decryption as suspicious network activity, making it unusable. Setup can also involve certificate installation and specific rule configurations.
  • Requestly: A browser extension (and standalone app) focused on modifying network requests. This often feels simpler for this specific use case.
    • My Experience: This worked much better for me! I used the Requestly Chrome add-on. The standalone app might work too, but the extension felt more straightforward.
    • Simplified Requestly Setup:
      1. Host Locally: Ensure your local build output (e.g., C:\PCFProject\out\controls\MyControl) is accessible via a local web server. Enabling IIS on Windows and setting up a simple website pointing to this folder on a specific port (e.g., http://localhost:7777) is one way described in the docs.
      2. Install Requestly: Add the extension to your browser.
      3. Create Rule: Create a “Replace Host” or “Redirect Request” rule.
         • Source Condition: The URL should contain a pattern unique to your deployed component, like [YourOrg].crm.dynamics.com/WebResources/your_namespace.your_control_name (the exact pattern might vary slightly).
         • Destination: Redirect to your local server address pointing to the specific file being requested, often the bundle.js. You might need a rule like: Replace https://[YourOrgUrl]/.../WebResources/your_namespace.your_control_name/bundle.js with http://localhost:7777/bundle.js. You might need separate rules or a more flexible rule for CSS/other resources if applicable.
      4. Activate & Refresh: Enable the rule in Requestly. Clear your browser cache and perform a hard refresh (Ctrl+Shift+R) on the Power App page the first time. Subsequent code changes should only require a normal refresh.

Key Benefit: This redirect method provides the best of both worlds: the rapid feedback loop of local development combined with the full context and real data of a live Dataverse environment.

Final Tips

• Source Maps: Ensure source maps are generated in your local development build (npm start watch does this by default). They are crucial for debugging your original TypeScript in the browser’s developer tools.
• ES5 vs ES6: By default, PCF components target ES5 JavaScript for broader browser compatibility. If you only need to support modern browsers, changing the target in tsconfig.json to ES6 can sometimes lead to cleaner transpiled code and slightly better debugging experiences, as ES6 features like classes map more directly to TypeScript. Remember to switch back to ES5 before creating your final production build if needed.

By understanding these different methods, you can choose the most efficient approach for debugging your PCF controls at each stage of development. While the local harness is great for quick UI checks, mastering the redirect technique with Requestly or Fiddler is key for efficiently tackling complex issues involving real data.

Datetime

const date = new Date("2025-03-31T20:00:00Z");
console.log(date.toString()); // Outputs: "Tue Apr 01 2025 09:00:00 GMT+1300 (New Zealand Daylight Time)"
console.log(date.toISOString()); // Outputs: "2025-03-31T20:00:00.000Z"

Without the suffix Z, the date time string is considered in local time zone. If it is actually in UTC, you will have an time zone offset issue.

const mydate = new Date("2025-03-31");
console.log(mydate.toString()); // Outputs: "Mon Mar 31 2025 00:00:00 GMT+1300 (New Zealand Daylight Time)"
console.log(mydate.toISOString()); // Outputs: "2025-03-30T11:00:00.000Z"

FakeXrmEasy made unit tests D365 really easy.

Unit testing CRUD operations is well proven and on the beaten path, however, the framework still have gaps in implemented fake message executors. For example, if the function you are testing contains QueryExpressionToFetchXmlRequest.

FakeXrmEasy.PullRequestException: Exception: The organization request type 'Microsoft.Crm.Sdk.Messages.QueryExpressionToFetchXmlRequest' is not yet supported...

Soution

Implement a FakeMessageExecutor

Futher limitation and a workaround

In the QueryExpressionToFetchXmlRequest instance, the FetchXml property of the QueryExpressionToFetchXmlResponse class is readonly.

So, let’s look into the matter. The QueryExpressionToFetchXmlResponse class inherits from the fundamental Microsoft.Xrm.Sdk.OrganizationResponse class. This base class provides a standardized structure for all responses returned from messages executed via the IOrganizationService. A key component of OrganizationResponse is the Results property.  

The Results property is of type ParameterCollection. This collection functions much like a dictionary, mapping string keys to object values. It serves as the standard mechanism through which output parameters from any organization service message are communicated back to the calling code.

So the solution is rather than populate the FetchXml property, populate the Results collection in the underlining class.

var response = new QueryExpressionToFetchXmlResponse();
response.Results["FetchXml"] = sb.ToString();

.Net library Requirements

Add System.Runtime.CompilerServices.Unsafe nuget package to your test project.

References

• http://www.bwmodular.org/blog/mocking-unimplemented-organisation-requests-in-fakexrmeasy
• [FakeXrmEasy v2 and v3 Custom APIs]https://dynamicsvalue.github.io/fake-xrm-easy-docs/quickstart/messages/custom-apis/

entry point input: context

output has two parts: the notification party and get output part

component property bags

service layer: json parsing

date time type

UserSettings > getTimeZoneOffsetMinutes https://learn.microsoft.com/en-us/power-apps/developer/component-framework/reference/usersettings/gettimezoneoffsetminutes

For format date time if we use format string we need moment If we use Locale string we need resx

Utility > Lookup property https://dianabirkelbach.wordpress.com/2021/06/19/lookup-pcf-lets-dive-deeper/

Notification bar

UI >

MessageBarType

Scenario: Title and details message

https://developer.microsoft.com/en-us/fluentui#/controls/web/messagebar

Scenario: Dismiss

onDismiss

Scenario: Multiple notifications

NotificationMessage[] then map to MessageBar JSX

Scenario: Timeout

Pagination:

https://markcarrington.dev/2021/02/23/msdyn365-internals-paging-gotchas/?utm_source=FetchXMLBuilder&utm_medium=XrmToolBox#multiple_linked_entities

### Browser event

In the Power Apps Component Framework (PCF), browser events are primarily managed through the notifyOutputChanged method and custom events defined in the component manifest.

It works better with canvas app but one issue I had is it triggers the whole PCF to refersh which leads it to loose all its states…

Install the PAC CLI tool for both the VS Code and Command Prompt for Windows

Install Power Platform CLI using Windows MSI

## Create a PCF solution folder

mkdir FileExplorerV9

Initialize the PCF solution structure

pac pcf init -ns Kys.CustomControl.FileExplorer -n src --template dataset -fw react -npm

pac pcf init --namespace SampleNamespace --name LinearInputControl --template field --run-npm-install

Initialize the Dataverse solution project

pac solution init --publisher-name KelvinBytes --publisher-prefix kys

pac solution add-reference --path FileExplorer

Multiple Gallery will lead to multiple scrolls in the 2nd level which is nasty.

However, two dimension nested gallery may work, i.e. level 1 gallery goes from left to right, and level 2 gallery goes from top to bottom.

Single Gallery with Grouped Items

Use a single gallery with grouped items technique

Data Join - The ForAll Technique

Using ForAll return nothing

ForAll(
    colAppEvents,
    Collect(
        colAppParties,
        Filter(
            'Application Parties',
            ThisRecord.Application.Application = Application.Application
        )
    )
);

Using ForAll with Alias for the outer loop

ForAll(
    colAppEvents As appEvent,
    Collect(
        colAppParties,
        Filter(
            'Application Parties',
            ThisRecord.Application.Application = appEvent.Application.Application
        )
    )
);

Using ForAll with With. With establish a temp variable

ForAll(
    colAppEvents,
    With(
        {currentApp: ThisRecord.Application.Application},
        Collect(
            colAppParties,
            Filter(
                'Application Parties',
                ThisRecord.Application.Application = currentApp
            )
        )
    )
)

Data Join - The Ungroup Technique

JOIN All Columns From Another Collection

Scope Ambiguity

Power Fx explained: Record scope, scope ambiguity and disambiguation

Single Quote vs Double Quote

SortByColumns is still using double quote to specify columns whereas AddColumns is using single quote to specify columns, or no quote if the column name has no spaces or speical characters.

Power Fx: Column names escape double quotes

Back in the old dates, for plugins depend on 3rd party assemblies, we need to do an ILmerge but it will mess up with debugging.

Now

Start from when we can now deploy plugin packages

Scenarios

Popular utility assemblies, for example:

• Newtonsoft.Json

Azure assemblies for integration, for example:

• Azure.Search.Documents
• Azure.Security.KeyVault.Secrets
• Azure.Storage.Blobs
• Azure.Storage.Queues

Although, previously we can send messages to Azure Queue via HttpClient without needing any 3rd party assemblies. Then, use Azure Function to do the heavy lifting. Now, Azure.Storage.Queues can make the coding experience eaiser.

Deployment

We cannot use sparkle xrm to deploy plugin packages.

Question unanswered

How is the debugging experience?