DEV Community: Ján

Dataverse Plugin Development in 2026: The Tooling Stack Explained

Ján — Sun, 04 Oct 2026 11:39:40 +0000

Dataverse plugin development no longer has one toolchain. The SDK, PAC CLI, Plug-in Registration Tool, Visual Studio tooling, native Git integration and plugin frameworks solve different layers of the problem. The important question is no longer "Which tool should I use?" but "Which tool should own which responsibility?"

A few years ago, a Dataverse project could easily grow around one utility.

The same tool might:

generate early-bound classes,
deploy the assembly,
register plugin steps,
deploy web resources,
export and import solutions,
pack and unpack solutions.

That made sense when first-party tooling covered less of the lifecycle.

In 2026, the picture is different.

Microsoft's Power Platform CLI now owns a much larger part of the developer and ALM surface. Power Platform Tools for Visual Studio can create, deploy, register, profile and debug plugins. The Plug-in Registration Tool still has a clear role. Dataverse now has native Git integration and a source-control-oriented YAML representation for solutions. Frameworks sit above that stack and add architecture, conventions and repeatability.

The result is not one "best tool".

It is a stack of responsibilities.

My rule for a modern Dataverse project is simple:

Use first-party tooling where the platform already has a good owner. Add a framework where you need architecture, consistency or stronger delivery guarantees.

Start with the platform: the Dataverse plugin SDK

Everything still starts with the Dataverse event framework.

A C# plugin executes because:

a Dataverse operation raises an event,
a plugin assembly or package is registered,
a step connects a plugin type to a message, table and pipeline stage,
Dataverse executes the code inside its plugin runtime.

At code level, the standard primitives are still familiar:

IPlugin
IPluginExecutionContext
IOrganizationService
ITracingService
Entity
EntityReference

A framework does not replace that contract.

It sits above it.

That matters because every abstraction eventually maps back to platform concepts such as:

message,
table,
pipeline stage,
synchronous or asynchronous execution,
filtering attributes,
pre/post images,
execution order,
configuration,
user context,
transaction behavior.

If an abstraction makes those concepts impossible to see, it has probably hidden too much.

Microsoft now owns much more of the tooling layer

The biggest change compared with older Dynamics development stacks is how much Power Platform CLI now covers.

It is no longer just an authentication helper.

Plugin projects: `pac plugin`

A new plugin class library can be initialized with:

pac plugin init

and an assembly or plugin package can be pushed with:

pac plugin push

For a Plain SDK project, that gives you a supported first-party path for project creation and deployment of the plugin binary/package.

What it does not solve by itself is the architecture inside the plugin or the full desired-state definition of every step.

That distinction is important.

Registration tooling: PRT still has a job

The Plug-in Registration Tool is still part of the supported Dataverse development workflow and can be launched through PAC CLI:

pac tool prt

(pac tool commands are available only in the .NET Framework build of PAC CLI, so in practice on Windows.)

PRT remains useful for:

registering and inspecting assemblies,
creating or editing steps,
inspecting images and filtering attributes,
troubleshooting existing environments,
profiling and replaying plugin executions,
understanding legacy solutions.

Power Platform Tools for Visual Studio can also register and manage plugin packages and provides an integrated profiling/debugging workflow.

So manual tooling is not obsolete.

The real question is whether manual state is your source of truth.

There is a big difference between:

"I use PRT to inspect and diagnose the environment."

and:

"Production is correct because somebody remembered which boxes to click."

The first is a useful tool.

The second is operational risk.

Typed code generation: `pac modelbuilder`

Microsoft's supported typed-code generator is:

pac modelbuilder build

Microsoft documents it as the replacement for CrmSvcUtil.exe distributed through the older Microsoft.CrmSdk.CoreTools package.

This is a good example of a responsibility that many frameworks no longer need to fully reimplement.

A framework can still add value through:

project conventions,
configuration,
wrappers,
generated helper files,
filtering rules,
onboarding.

But the underlying code-generation engine can remain first-party.

That is the approach Pillaro takes today.

Solution lifecycle: `pac solution`

The pac solution command group covers a large part of the solution lifecycle, including operations such as:

initialization,
cloning,
synchronization,
export/import,
pack/unpack,
checks,
versioning,
upgrades.

Microsoft explicitly states that standalone SolutionPackager is no longer the recommended way to pack and unpack solutions because that capability is incorporated into PAC CLI.

For a plugin framework, that changes the scope discussion.

A framework should have a strong reason before it starts owning generic solution packaging in 2026.

Native Git integration changes the ALM picture again

This is one of the biggest changes to the 2026 tooling stack.

Dataverse now has native Git integration for solution source control.

That means a development environment or solution can be connected directly to a supported Git provider, and makers can commit and synchronize Dataverse solution changes with source control from the Power Platform experience.

At the time of writing:

the integration is generally available for Azure DevOps (since April 2025) and requires Managed Environments,
GitHub support is in public preview (since August 2026),
Microsoft recommends using the integration in development environments and using builds/pipelines to deploy downstream.

The source-control representation is also changing.

Dataverse Git integration uses a YAML-based source format, and pac solution clone can produce the same format for code-first workflows.

That matters because the ALM stack is moving further toward:

Development environment
        ↕
Git source of truth
        ↓
Build
        ↓
Solution artifact
        ↓
Test / Production

instead of:

Development environment
        ↓
Export ZIP
        ↓
Hope the repository reflects reality

This does not remove the need for plugin source code, build pipelines or deployment conventions.

It does make source control a much more first-class part of the platform.

Visual Studio is another valid first-party path

Power Platform Tools for Visual Studio supports a substantial part of the plugin lifecycle.

It can help with:

plugin project creation,
package creation,
uploading and registering packages,
registration management,
profiling,
replay debugging.

This matters because "Plain SDK" no longer means:

write a DLL and manually do everything else.

There is now a meaningful first-party developer experience around the SDK.

A framework therefore has to add value above that baseline.

The stack by responsibility

This is how I currently separate the layers.

Responsibility	First-party / platform layer	Optional higher-level layer
Plugin execution contract	Dataverse SDK	Framework execution model
Create plugin project	`pac plugin init`, Visual Studio tools	Framework templates/scaffolding
Build/package plugin	.NET + plugin package tooling	Framework build conventions
Push plugin binary/package	`pac plugin push`, Visual Studio tools	Framework deployer
Register/inspect steps	PRT, Visual Studio tools	Framework registration model
Define registration as code	Team automation	Plugin framework
Generate typed entities	`pac modelbuilder`	Framework wrapper/convention
Pack/unpack solutions	`pac solution`	Usually no framework needed
Source-control solution metadata	Dataverse Git integration / `pac solution clone`	Team ALM conventions
Environment authentication	`pac auth`	CI/CD secret conventions
Runtime architecture	Your code	Plugin framework
Validation structure	Your code	Plugin framework
Diagnostics	Dataverse tracing/profiler	Framework diagnostics
Testing conventions	Your test stack	Framework test package
Registration synchronization	Your CI/tooling	Framework deployer
Web-resource delivery	Platform/CI tooling	Some broader frameworks
Live remote debugging	Profiler/replay or framework-specific tooling	XrmFramework-style remote debugging

The important pattern is that the modern stack is composable.

You do not need one dependency to own every row.

Three reasonable project shapes

Most Dataverse plugin projects can be described by one of three approaches.

1. Minimal first-party stack

Dataverse SDK
    +
pac plugin
    +
PRT / Visual Studio tools
    +
pac modelbuilder
    +
pac solution
    +
Git / Dataverse Git integration

This is a strong choice when:

the solution has only a few plugins,
the team understands the Dataverse pipeline well,
internal conventions are enough,
third-party dependencies are undesirable,
registration complexity is limited.

There is nothing second-class about this architecture.

It has the smallest dependency surface.

The trade-off is simple:

your team owns the architecture and conventions.

That includes decisions such as:

how plugin classes are structured,
how validation is separated from execution,
how steps are represented,
how environments are kept consistent,
how testing is done.

2. Structured framework stack

Dataverse SDK
        ↓
Plugin framework
        ↓
Architecture + registration + diagnostics + testing

plus

PAC CLI / Git / platform ALM tooling

This makes sense when the recurring problem is no longer project creation.

The problem is consistency.

A framework can add:

repeatable plugin structure,
explicit execution units,
registration in code,
validation conventions,
diagnostics,
integration testing,
deterministic deployment,
onboarding standards.

The principle I prefer is:

Use the framework where it adds architecture. Keep first-party tooling where the platform already has a strong owner.

For example, Pillaro provides project-local helpers for early-bound generation, but the actual generator remains pac modelbuilder.

For solution lifecycle, PAC CLI remains the intended layer.

That keeps the boundaries clearer.

3. Existing / legacy tooling stack

Many mature solutions still look more like this:

Dataverse SDK
    +
spkl
    +
older SDK tooling
    +
custom scripts

That is not automatically wrong.

If the project is stable, the deployment process is understood and the toolchain still works, migration may create more risk than value.

But for an actively developed solution, I would periodically ask:

Are the Microsoft dependencies current?
Does authentication still match modern tenant requirements?
Is the deployment tool still a good long-term dependency?
Are solution operations now better owned by PAC CLI?
Is typed-code generation better handled by pac modelbuilder?
Is plugin registration reproducible?
Is the tool still present because it adds unique value, or because it historically owned five responsibilities at once?

That was the reason for the first article in this series: moving from spkl is not mainly about replacing one executable with another.

It is about deciding who should own each responsibility now.

Frameworks belong above the generic tooling layer

I find it useful to draw the architecture like this:

┌─────────────────────────────────────────────┐
│ Business logic / plugin architecture        │
│ Tasks, services, validation, conventions    │
│                  FRAMEWORK                  │
├─────────────────────────────────────────────┤
│ Registration / deployment invariants        │
│ Framework deployer or team automation       │
├─────────────────────────────────────────────┤
│ Source control / ALM                        │
│ Git integration / pipelines / pac solution  │
├─────────────────────────────────────────────┤
│ Microsoft developer tooling                 │
│ pac plugin / modelbuilder / PRT / VS tools  │
├─────────────────────────────────────────────┤
│ Dataverse SDK + event framework             │
└─────────────────────────────────────────────┘

This makes framework scope easier to reason about.

A framework is strongest when it owns the layers where team consistency, architecture and delivery invariants matter.

It becomes harder to justify when it simply recreates generic platform tooling that Microsoft already maintains.

Where XrmFramework fits

As discussed in Part 3, XrmFramework deliberately owns a broad part of the upper stack.

Its current development model includes areas such as:

declarative plugin registration,
typed metadata/model tooling,
service architecture,
Custom API tooling,
deployment utilities,
Roslyn generation/analyzers,
scaffolding,
web-resource tooling,
remote debugging.

That is a coherent strategy:

make Dataverse development feel like a more integrated .NET development platform.

For teams that want that breadth, the framework can become the center of the developer experience.

Where Pillaro fits

Pillaro intentionally owns a narrower set of upper-layer responsibilities.

Its current center is:

task-based execution,
explicit validation and execution phases,
registration metadata in code,
stable step identity,
deployment synchronization,
structured diagnostics,
runtime configuration,
integration testing against real Dataverse.

For early-bound generation, Pillaro uses project-local helper tooling around Microsoft's:

pac modelbuilder build

For the general solution lifecycle, PAC CLI remains the intended owner.

For repository and environment ALM, standard Git and Power Platform tooling remain outside the framework.

The strategy is:

own the plugin architecture and delivery invariants; reuse Microsoft tooling for generic platform lifecycle operations.

Pillaro is listed in Microsoft Learn's Community Tools for Microsoft Dataverse catalog and is distributed through Microsoft Marketplace for the Dataverse-side runtime, while the C# framework is consumed through NuGet.

That improves discovery and deployment, but it does not change the support model: Pillaro remains a community-maintained framework.

Where PRT still fits

There is a temptation to call GUI tools obsolete once CI/CD exists.

I do not think that is accurate.

PRT is still useful when you need to:

inspect what is really deployed,
diagnose a registration,
profile a plugin,
test an idea in a development environment,
understand a legacy solution,
compare expected and actual state.

The problem is not the GUI.

The problem is undocumented state.

A healthy setup can use PRT every week and still have fully reproducible deployments.

Where AI-assisted development changes the equation

AI makes code generation cheaper.

It does not make architecture less important.

In practice, coding agents work better when a repository has:

predictable project structure,
explicit registration,
small units of behavior,
clear validation rules,
reusable tests,
deterministic deployment,
useful diagnostics.

The same is true for human developers.

As code becomes easier to generate, the value shifts away from:

"Who can type the C# fastest?"

toward:

"Is the intended behavior explicit enough to implement, verify, review and operate repeatedly?"

That is an architecture and delivery problem.

It is one reason I expect frameworks and internal engineering standards to remain relevant.

My default approach for a new Dataverse plugin project in 2026

I would make the decisions in this order.

1. First ask whether you need a plugin

Microsoft still recommends considering declarative business-logic options first.

Use custom C# because the requirement needs transactional code, platform event handling, performance, complex integration logic or another capability that declarative options cannot reasonably provide.

Not because "we always use plugins."

2. Start with current Microsoft tooling

For the responsibilities Microsoft already owns well, use the platform tools:

pac plugin
pac modelbuilder
pac solution
pac tool prt
Power Platform Tools for Visual Studio

For solution source control, evaluate native Dataverse Git integration and the current YAML source format.

Avoid adding a second owner for the same responsibility without a clear reason.

3. Decide how plugin architecture will be standardized

Choose explicitly between:

Plain SDK + team conventions,
an internal standard/framework,
a public framework.

Do not let the architecture emerge accidentally plugin by plugin.

4. Put registration state under control

A build artifact is not enough.

You also need to know:

which step runs,
on which message,
on which table,
in which stage,
synchronously or asynchronously,
which attributes trigger it,
which images exist,
under which user context,
in what order it executes.

That state should be reviewable and reproducible.

5. Put solution state under source control

Plugin source code and Dataverse solution metadata solve different problems.

Both matter.

In 2026 there are stronger first-party options than before:

Dataverse Git integration,
YAML-based solution source representation,
pac solution clone,
standard CI/CD pipelines.

The exact workflow can differ between teams.

The important part is that source control—not someone's development environment—becomes the durable source of truth.

6. Decide what "tested" means

There is a large difference between:

unit-testing a service,
simulating a plugin context,
integration-testing against Dataverse,
replay-debugging a captured execution,
end-to-end verification after deployment.

Use the level that matches the risk.

But decide deliberately.

7. Keep the stack replaceable

Every additional tool should have a clear boundary.

If the framework owns plugin architecture, let it own plugin architecture.

If PAC CLI owns generic solution packaging, let PAC CLI own it.

If Git owns source history, do not hide the only source of truth inside an environment.

Clear boundaries make future migrations much easier.

The series in one picture

The four articles in this series map to four different decisions:

Part 1
Existing spkl project
        ↓
What should replace the responsibilities it owns?

Part 2
Plain SDK project
        ↓
When does framework abstraction pay off?

Part 3
Framework decision
        ↓
Pillaro or XrmFramework-style approach?

Part 4
Whole developer stack
        ↓
Which tool should own which responsibility?

That is the main point of the series.

There is no single correct Dataverse plugin stack.

There should, however, be a clear reason for every layer you add.

Closing thought

A mature development stack is not the stack with the most tooling.

It is the stack where ownership is obvious.

When something breaks, you should be able to ask:

Is this a Dataverse runtime problem?
An SDK problem?
A registration problem?
A PAC CLI / ALM problem?
A framework problem?
A business-logic problem?
A pipeline problem?

And know where to look.

That clarity is more valuable than any individual feature.

Sources

Disclosure: I maintain Pillaro. This article is a tooling map, not a recommendation that every Dataverse project should use Pillaro or any other framework. Tooling status reviewed in October 2026.

Pillaro and XrmFramework: Two Different Approaches to Dataverse Plugin Development

Ján — Sun, 04 Oct 2026 10:27:14 +0000

XrmFramework and Pillaro both try to reduce friction in Dataverse plugin development. They do it from different starting points: one optimizes for a broad productivity stack, the other for an explicit task lifecycle, deterministic registration and real-environment testing.

This is the comparison in this series where the tools really do overlap.

Both XrmFramework and Pillaro are actively maintained Dataverse development frameworks.

Both move plugin registration closer to code.

Both provide project structure and deployment tooling.

Both try to make Dataverse development more predictable than repeating raw SDK plumbing in every project.

But they are not trying to build the same product.

That makes a simple feature-count comparison less useful than it first appears.

The better question is:

What development model does each framework want your team to adopt?

Disclosure: I maintain Pillaro. I have tried to describe XrmFramework from its current repository and documentation, including the parts where it is clearly broader or more mature.

Pillaro is listed in Microsoft Learn's Community Tools for Microsoft Dataverse catalog and is published in Microsoft Marketplace. The Marketplace offer installs the Dataverse-side managed solution the framework depends on, including the model-driven app for configuration and diagnostic logs; development teams consume the C# framework through NuGet.

These listings improve discoverability and distribution, but the Microsoft Learn catalog explicitly states that community tools are supported by their publishers rather than by Microsoft.

Microsoft Learn listing · Microsoft Marketplace

The short version

If you want the comparison in one paragraph:

XrmFramework is the broader productivity platform. It includes typed model tooling, a service-oriented architecture, declarative plugin registration, Custom API deployment, Roslyn analyzers, project templates, web-resource deployment utilities and a live remote debugger.

Pillaro is narrower and more opinionated around the plugin execution lifecycle. It centers development around small tasks with explicit validation and execution phases, stable registration identity, deterministic deployment, structured diagnostics and integration tests that run against a real Dataverse environment.

Neither design is universally better.

They optimize different things.

XrmFramework's design center: remove Dataverse development friction

The XrmFramework README describes its goal as making Dynamics 365 / Dataverse development feel more like modern .NET.

That is visible across the project.

Plugin steps are declared in code

A plugin inherits from the framework Plugin base class and defines steps in AddSteps():

protected override void AddSteps()
{
    AddStep(
        Stages.PreValidation,
        Messages.Create,
        Modes.Synchronous,
        AccountDefinition.EntityName,
        nameof(Method1));

    AddStep(
        Stages.PostOperation,
        Messages.Update,
        Modes.Synchronous,
        AccountDefinition.EntityName,
        nameof(Method2));
}

Additional registration metadata is attached to the target method with attributes:

[PreImage(AccountDefinition.Columns.Name)]
[PostImage(AccountDefinition.Columns.Name)]
[FilteringAttributes(
    AccountDefinition.Columns.Name,
    AccountDefinition.Columns.AccountNumber)]
[ExecutionOrder(100)]
public void Method(...)
{
}

Deployment then registers those steps in Dataverse.

Strongly typed models are a major part of the experience

XrmFramework 3.1+ makes .table files the source of truth for Dataverse table metadata. Typed table, column and option-set definitions are generated at compile time by a Roslyn source generator.

Binding models can be described in .model files and generated the same way, including the mapping code between Dataverse entities and typed models.

The files can be produced and maintained through XrmFramework tooling, including the Definition Manager and the xrmframework CLI.

The design goal is clear:

reduce magic strings and make Dataverse metadata refactor-friendly.

The 3.1 line is a stable release on NuGet, and the xrmframework CLI includes a one-time migration path for 2.x solutions.

Business logic is organized into services

XrmFramework has an IService architecture for data access and business logic.

Those typed services can be injected into plugin methods, Custom APIs and external code.

That gives the framework a larger architectural surface than only the plugin entry point.

Custom APIs are first-class

The framework supports defining modern Dataverse Custom APIs from C# and deploying the related:

customapi,
customapirequestparameter,
customapiresponseproperty

metadata.

For teams using Custom APIs heavily, that is significant.

Remote debugging is a differentiator

XrmFramework includes a remote debugger that forwards a real Dataverse plugin execution to the developer's machine over Azure Relay.

You can set a Visual Studio breakpoint and step through the execution locally.

Pillaro does not have an equivalent feature.

The tooling surface is broad

The current project also includes:

xrmframework CLI scaffolding for solutions and projects,
deployment utilities,
Roslyn source generators, analyzers and code fixes,
TypeScript tooling,
web-resource deployment,
unit-test helpers,
tracing utilities.

XrmFramework has also been around for years and its NuGet packages have accumulated hundreds of thousands of downloads.

This is a mature, broad toolchain.

Pillaro's design center: make the execution model explicit

Pillaro started from a narrower set of problems.

The recurring issues we wanted to remove were:

plugin classes where validation and execution gradually became mixed,
registration that drifted between environments,
duplicate or stale plugin steps,
tests that did not verify the real deployed behavior,
and solutions where every plugin ended up with a slightly different internal structure.

The framework therefore makes the execution unit a Task.

A task has an explicit lifecycle

The simplified model is:

Plugin
  ↓
Task
  ├─ Validation
  └─ Execution

A task declares its validations separately from its business logic:

public class MyFirstTask(
    IServiceProvider serviceProvider,
    TaskContext taskContext)
    : TaskBase<Logic.Task>(serviceProvider, taskContext)
{
    protected override ICompleteValidation AddValidations(
        IBasicModeValidation validator)
    {
        return validator
            .WithMode(PluginMode.Synchronous)
            .WithStage(PluginStage.Preoperation)
            .WithMessages(["Create"])
            .ForEntity(ContextEntity.LogicalName);
    }

    protected override void DoExecute()
    {
        // Business logic
    }
}

The framework is deliberately opinionated here.

The split between validation and execution is not a convention that every team member has to remember. It is part of the model.

Runtime task registration and deployment registration are separate

The plugin decides which tasks participate in runtime execution (in these samples, Task is the Dataverse activity table, not the framework concept):

RegisterTask<MyFirstTask>(
    PluginStage.Preoperation,
    ["Create"],
    Task.EntityLogicalName,
    PluginMode.Synchronous);

Deployment metadata is declared separately:

public override void Register(IPluginRegistration registration)
{
    registration
        .OnCreate<Task>("8c46d6e6-3c25-4b9d-9264-6c0d02b4d2f1")
        .PreOperation()
        .Synchronous()
        .Rank(1);
}

The explicit step ID gives registration a stable identity across deployments.

Deployment is treated as synchronization

Pillaro's deployment tooling reads registration metadata from code and synchronizes the assembly, steps, images, filtering attributes, rank, configuration and solution membership.

The desired direction is:

Registration in code
        ↓
Compare with Dataverse
        ↓
Synchronize state

That is intentionally different from a deployment model where code only adds what is missing.

Testing targets real Dataverse

Pillaro's test package is built around integration tests against an actual Dataverse environment with deployed plugins.

A test can:

create tracked test data,
trigger the real operation,
let Dataverse execute the deployed plugin,
verify the outcome,
clean up test data.

That gives a different testing emphasis than a unit-test helper package.

Diagnostics are part of the runtime model

The framework includes execution-flow logging, task-level diagnostics, timings and depth information.

The design preference is to make production behavior inspectable without making live debugging the primary development path.

Pillaro does not provide XrmFramework-style remote debugging.

The comparison

Here is the current high-level picture.

Area	XrmFramework	Pillaro
Main design center	Broad Dataverse developer productivity	Explicit plugin/task lifecycle and repeatable delivery
Execution unit	Plugin step routed to a method	Plugin orchestrates one or more Tasks
Validation/execution split	Team convention	Explicit framework lifecycle
Step declaration	`AddStep(...)` + method attributes	`Register(IPluginRegistration)` fluent API
Stable explicit step ID	Not the central public API model	Required by registration API
Typed metadata	`.table` / `.model` source files + Roslyn generation + XrmFramework tooling	Early-bound helper tooling around `pac modelbuilder`
Service architecture	Typed `IService` classes and injection	Task/context model + framework services/features
Custom API tooling	Custom API, parameters and response properties deployed from C#	Main-operation tasks; the Custom API definition stays in the solution
Build-time diagnostics	Roslyn analyzers and fixes	No equivalent analyzer suite today
Live remote debugging	Yes, over Azure Relay	No
Runtime diagnostics	Rich tracing	Structured plugin/task diagnostics and performance data
Unit-test helpers	Yes	Framework focus is not mocked unit execution
Tests against real Dataverse	Build your own approach	Built-in integration testing stack
Web-resource tooling	Yes	No
Project scaffolding	`xrmframework new ...` CLI	`dotnet new` + Visual Studio VSIX
Plugin deployment	Built-in deployment utilities	Built-in synchronization/deployment tooling
Solution pack/unpack	Not the core comparison	Delegated to PAC CLI
License	MIT	Apache-2.0
Project maturity	Established, years of usage	Newer framework, first stable generation in 2026

There are deliberately no "winner" ticks in this table.

A feature only matters if your team needs it.

The biggest architectural difference

The most important distinction is not remote debugging or model generation.

It is where each framework places the center of gravity.

XrmFramework's center is the broader developer experience:

Typed models
Services
Plugin methods
Custom APIs
Analyzers
Deployment
Remote debugging
Web resources

Pillaro's center is the execution and delivery model:

Plugin
  ↓
Task
  ├─ explicit validation
  └─ explicit execution
  ↓
registration as desired state
  ↓
deployment synchronization
  ↓
real-environment tests

That difference affects how teams structure their code.

Typed metadata: two valid approaches

Both frameworks try to reduce raw logical-name strings, but the tooling is different.

XrmFramework

In XrmFramework 3.1+, .table files are the source of truth for table metadata. A Roslyn source generator turns them into typed *Definition classes and option-set enums at compile time.

The same model extends to binding models: .model files describe the typed shape and the generator emits the corresponding class and entity-mapping code.

The files can be created or refreshed from Dataverse through XrmFramework tooling such as the xrmframework CLI, while the generated C# does not need to be checked into source control.

This is a framework-owned typed metadata experience with a source-generation model.

Pillaro

Pillaro currently builds its typed entity workflow around Microsoft's Power Platform CLI.

The plugin package generates helper files under Tools/EarlyBound/, but the underlying generator is:

pac modelbuilder build

That is a deliberate design choice.

Pillaro provides the project convention and wrapper; Microsoft owns the actual model generator.

Neither approach is inherently superior.

One provides a more integrated framework experience.

The other keeps the metadata generation boundary closer to first-party tooling.

Debugging vs observability

This is one of the clearest differences.

XrmFramework: debug the live execution

Its remote debugger is compelling when the team wants to:

reproduce a difficult runtime path,
attach a breakpoint,
inspect local state step by step,
debug against a real environment.

Nothing in Pillaro currently replaces that.

Pillaro: make executions inspectable

Pillaro takes a different direction:

structured execution flow,
task-level logging,
performance timing,
depth tracking,
repeatable real-environment tests.

The aim is to reduce the number of cases where a developer needs an attached debugger at all.

Those are different engineering preferences.

Some teams will want both ideas.

Testing: simulated isolation vs deployed behavior

Testing is another place where the word "testing" can hide very different things.

XrmFramework publishes XrmFramework.Tests, described in its package list as unit-test helpers for plugins and services.

That is useful when you want fast isolated feedback around framework code.

Pillaro's built-in testing stack intentionally does something else.

It requires a Dataverse environment with the plugin already deployed.

The test then creates or modifies actual Dataverse records and verifies the resulting behavior.

That makes the tests slower and dependent on an environment.

It also means they verify things a mocked test cannot fully verify:

actual registration,
actual pipeline execution,
platform behavior,
interactions between deployed plugins,
real Dataverse data operations.

A mature project may want both unit-level and integration-level coverage.

The frameworks simply emphasize different layers.

Breadth has a cost — and narrowness has a cost

XrmFramework's breadth is a benefit when you want one coherent stack.

It also means there is more framework to adopt:

model definitions,
service architecture,
deployment utilities,
analyzers,
debugger,
Custom API conventions,
potentially web-resource tooling.

If your team wants those things, the integration is valuable.

If your problem is only plugin structure and deterministic registration, it may be more surface than you need.

Pillaro has the opposite trade-off.

It does not currently provide:

a remote debugger,
XrmFramework's analyzer suite,
TypeScript/web-resource tooling,
Custom API definitions deployed from code (Pillaro runs the main-operation task, but the customapi records and their parameters stay in your solution),
the same years of ecosystem maturity.

If your team needs those features, that matters.

A smaller surface is only an advantage when the smaller surface contains the things you actually need.

When XrmFramework is a natural fit

XrmFramework deserves serious consideration when your team wants a broad Dataverse development platform and values several of these together:

framework-owned typed model tooling,
a service-oriented architecture across plugins and external code,
full Custom API tooling,
Roslyn diagnostics,
remote debugging,
web-resource deployment,
a mature package ecosystem,
years of production usage.

It is especially interesting when the goal is:

remove as much recurring Dataverse development friction as possible through one integrated framework.

When Pillaro is a natural fit

Pillaro is aimed more directly at teams that care about:

explicit task-sized units of business logic,
enforced validation → execution structure,
stable registration identity,
registration synchronized from code,
avoiding duplicate/stale plugin steps,
structured diagnostics,
integration tests against real Dataverse,
using Microsoft tooling such as pac modelbuilder where it already solves the problem.

The design goal is closer to:

keep the framework surface focused, but make the plugin lifecycle and delivery model highly explicit.

Migration cost matters more than feature tables

If you already have a large XrmFramework solution, this article is not an argument to migrate it.

A framework replacement changes more than NuGet packages.

It can affect:

architecture,
project structure,
registration,
tests,
deployment,
developer habits,
operational tooling.

A migration only makes sense when the destination solves a real problem that justifies that cost.

The same is true in the opposite direction.

If a Pillaro project needs capabilities that are central to XrmFramework, the feature gap should be evaluated honestly instead of forcing a smaller framework to become something it was not designed to be.

My conclusion

I do not think the useful conclusion is:

XrmFramework is for large projects and Pillaro is for small projects.

That is too simplistic.

A better distinction is:

XrmFramework optimizes for breadth of developer productivity.

Pillaro optimizes for explicitness of plugin architecture, deployment state and deployed-behavior verification.

Those priorities can exist in projects of very different sizes.

The right choice depends on which source of friction your team actually wants the framework to own.

What comes next

The final article in this series zooms out.

Instead of comparing frameworks, Part 4 maps the Dataverse plugin tooling stack in 2026:

what belongs to the SDK,
what PAC CLI now owns,
where PRT still fits,
what frameworks add,
and where older deployment tools such as spkl fit in a modern codebase.

Sources

Disclosure: I maintain Pillaro. XrmFramework descriptions in this article are based on its current public repository and documentation as reviewed in October 2026. Corrections are welcome.

Plain SDK vs a Plugin Framework: When Does the Abstraction Pay Off?

Ján — Mon, 28 Sep 2026 07:09:00 +0000

The Dataverse SDK is not something you graduate from. A framework only earns its place when it removes recurring engineering cost without hiding the platform you still need to understand.

A Dataverse plug-in can be very small.

You implement IPlugin, read the execution context, do the work, register the step, and move on.

For a single internal plug-in, that can be exactly the right solution.

The interesting question starts later.

What happens when one plug-in becomes twenty? When multiple developers touch the same solution? When DEV, TEST and PROD no longer have exactly the same registrations? When every new plug-in starts by copying the same context, tracing, validation and registration patterns?

That is where teams usually start asking whether they need a framework.

The useful question is not:

Should every Dataverse project use a plug-in framework?

It is:

At what point does the cost of repeating the same engineering decisions become higher than the cost of adopting an abstraction?

That is what this article is about.

TL;DR

Plain SDK is a valid architecture. A small, stable plug-in does not need a framework just because one exists.
Frameworks start paying for themselves when repetition becomes delivery risk — more developers, more environments, more registrations, longer solution lifetime and a stronger need for repeatable tests.
The real decision is who owns the conventions the SDK leaves open: each developer, your internal standards, or a framework.

What the Plain SDK gives you in 2026

The standard Dataverse plug-in model is still the foundation.

A plug-in is a class that implements IPlugin and executes because a registered Dataverse step connects that class to an event in the Dataverse execution pipeline.

Microsoft's supported model still revolves around:

IPlugin,
IPluginExecutionContext,
IOrganizationService,
plug-in assemblies and packages,
message processing steps,
images,
filtering attributes,
the Plug-in Registration Tool,
Power Platform CLI,
and Power Platform Tools for Visual Studio.

The first-party tooling around the SDK has improved considerably.

Power Platform CLI can initialize a plug-in project:

pac plugin init

and can import a plug-in assembly or package into Dataverse:

pac plugin push

The Plug-in Registration Tool is still supported and can be launched through:

pac tool prt

Power Platform Tools for Visual Studio can create, register, deploy, debug and profile plug-ins as well.

So the reason to adopt a framework in 2026 is not that Microsoft gives you no tooling.

It is also important to separate two concerns:

Getting plug-in code into Dataverse
              ≠
Defining exactly when and how it executes

An assembly can be present while the registration around it is still wrong.

That distinction becomes increasingly important as a solution grows.

A small plug-in may not need a framework

Imagine a plug-in with one responsibility:

On Account update, reject a change if a specific business condition is not satisfied.

A straightforward SDK implementation may be entirely reasonable:

public class ValidateAccountPlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context =
            (IPluginExecutionContext)serviceProvider
                .GetService(typeof(IPluginExecutionContext));

        if (!context.InputParameters.TryGetValue("Target", out var targetValue))
            return;

        if (targetValue is not Entity target)
            return;

        if (target.LogicalName != "account")
            return;

        if (!target.Contains("name"))
            throw new InvalidPluginExecutionException(
                "Account name is required.");
    }
}

There is nothing inherently wrong with this.

For a tiny project, adding another dependency, another execution model and another deployment convention may create more complexity than it removes.

Zero framework is a valid architecture.

A framework should have to justify itself.

Where the cost starts to appear

The SDK gives you platform primitives.

It deliberately does not prescribe the architecture of your whole solution.

That freedom is useful, but the team has to provide the missing discipline.

As the solution grows, the same categories of work tend to repeat.

Execution boilerplate

Every plug-in needs some combination of:

execution context,
target handling,
pre/post images,
organization services,
tracing,
configuration,
stage/message checks,
error handling.

A good team can centralize this themselves.

A less disciplined codebase gradually gets twenty slightly different versions of the same thing.

Validation mixed with execution

The SDK does not force you to separate:

Can this operation run?

from:

What should this operation do?

That separation is an architectural decision.

Without a convention, plug-in classes often accumulate both.

Registration lives somewhere else

The business code can be perfectly version controlled while the actual plug-in step still exists only as a Dataverse record.

That means the complete behavior is:

code + deployed registration

not just:

code

If registration is not reproducible, source control is only telling part of the story.

Environment drift

A common operational problem is not a broken DLL.

It is an environment that contains:

an old step,
a disabled step,
different filtering attributes,
a missing image,
a different execution order,
or a duplicate registration.

The application can compile successfully while DEV and PROD still behave differently.

Testing becomes inconsistent

Plain SDK code can absolutely be tested.

The SDK does not make code untestable.

But the team has to decide:

what is isolated from the plug-in entry point,
what gets mocked,
whether pipeline behavior is simulated,
whether anything is tested against real Dataverse,
how test data is created and removed.

Again: freedom means the team owns the convention.

Five signals that an abstraction may start paying for itself

There is no plug-in count at which a framework suddenly becomes mandatory.

But there are useful signals.

1. You are repeating the same structure

If every new plug-in starts by copying another plug-in and deleting half of it, you already have an implicit framework.

It just lives in copy-paste.

At that point, formalizing the pattern can reduce variance.

2. Registration is part of delivery risk

If deployment requires someone to open the Plug-in Registration Tool and verify steps manually, registration has become part of your delivery process.

For a small solution, that may be acceptable.

For a team shipping frequently across several environments, it becomes an operational dependency.

3. The project needs repeatable tests

The value of reusable test infrastructure increases with the lifetime of the solution.

A plug-in that changes once a year can survive manual verification.

A business-critical implementation that changes every sprint benefits much more from repeatable regression tests.

4. More developers need to understand the same codebase

Frameworks can reduce local creativity.

That sounds negative, but in a large codebase it is often useful.

If every plug-in has the same shape, a developer can move between features without first reverse-engineering the author's preferred pattern.

5. The solution will live for years

The longer a solution lives, the more expensive inconsistency becomes.

The first plug-in is cheap.

The fiftieth deployment, third developer and fourth environment are where architectural decisions start compounding.

What a framework should actually buy you

A framework should not be measured by how many classes it adds.

It should be measured by which recurring problems disappear.

For a Dataverse plug-in project, useful framework responsibilities can include:

Problem	Plain SDK	What a framework can add
Plug-in execution	Platform primitives	Consistent execution pipeline
Validation	Team convention	Explicit validation lifecycle
Step registration	PRT / VS tooling / custom automation	Registration defined in code
Environment consistency	Team/CI responsibility	Deterministic registration synchronization
Diagnostics	`ITracingService` + custom patterns	Standard structured logging
Testing	Build your own approach	Reusable unit/integration test foundation
Project structure	Team decision	Consistent templates and conventions
Onboarding	Learn project-specific patterns	Predictable project shape

A framework does not remove the SDK.

It organizes how the team uses it.

There is also an emerging AI-assisted development benefit to making those conventions explicit. Small task-sized units, code-defined registration and executable tests give coding agents clearer boundaries and feedback than a large plug-in class whose behavior has to be inferred. Pillaro explicitly treats this as part of its AI-Ready Standard — not as autonomous development magic, but as a way to make the codebase easier for both developers and AI tools to reason about.

A concrete example: the Pillaro approach

Pillaro is one possible answer to these problems.

Disclosure: I maintain it.

It is open source under Apache-2.0, free to use in commercial projects, and production-proven. The framework's first production adopter was Seyfor, where it has been deployed in enterprise Dynamics 365 and Power Platform solutions.

Starting a new solution does not have to mean wiring the framework, testing package and early-bound tooling by hand. Pillaro ships official starter templates for both dotnet new (CLI, VS Code, Visual Studio) and a Visual Studio VSIX template, generated from the same shared source so both produce an identical project structure.

For the fastest path to a running task-based plug-in project:

dotnet new install Pillaro.Dataverse.PluginTemplate.DotNetNew
dotnet new pillaro-dataverse-plugin-dotnet -n MySolution

That is often the practical answer to "I just need one plug-in fast" — you get the task/validation structure, code-defined registration, testing package and early-bound tooling already wired, instead of assembling them by hand.

Pillaro is also listed in Microsoft Learn's Community Tools for Microsoft Dataverse catalog and is published in Microsoft Marketplace. The Marketplace offer installs the Dataverse-side runtime used by the framework, while the C# framework itself is consumed as a NuGet package.

Microsoft Learn explicitly notes that community tools are supported by their publishers rather than by Microsoft.

Microsoft Learn listing · Microsoft Marketplace

The framework uses a task-based model where validation and execution are explicit phases:

A task follows a consistent lifecycle:

public class MyFirstTask(
    IServiceProvider serviceProvider,
    TaskContext taskContext)
    : TaskBase<Logic.Task>(serviceProvider, taskContext)
{
    protected override ICompleteValidation AddValidations(
        IBasicModeValidation validator)
    {
        return validator
            .WithMode(PluginMode.Synchronous)
            .WithStage(PluginStage.Preoperation)
            .WithMessages(["Create"])
            .ForEntity(ContextEntity.LogicalName);
    }

    protected override void DoExecute()
    {
        // Business logic
    }
}

The plug-in then registers that task for runtime execution:

RegisterTask<MyFirstTask>(
    PluginStage.Preoperation,
    ["Create"],
    Task.EntityLogicalName,
    PluginMode.Synchronous);

Deployment metadata is declared separately:

public override void Register(IPluginRegistration registration)
{
    registration
        .OnCreate<Task>("8c46d6e6-3c25-4b9d-9264-6c0d02b4d2f1")
        .PreOperation()
        .Synchronous()
        .Rank(1);
}

That separation is intentional.

RegisterTask(...) tells the runtime which task to execute.

Register(IPluginRegistration registration) tells deployment tooling which Dataverse registration should exist.

The stable step ID gives the deployment model a persistent identity for the step, while the deployment tooling synchronizes the declared registration with Dataverse.

Pillaro also provides functional testing infrastructure that runs against a real Dataverse environment with deployed plug-ins and cleans up tracked test data afterwards.

That is one design choice.

Other frameworks make different choices.

The point is not that this is the only valid architecture. It is an example of what it means for a framework to own repeated conventions on purpose.

What a framework should not do

A framework can solve real problems and still be the wrong choice.

There are several failure modes worth watching for.

It should not hide Dataverse from you

A developer using a framework still needs to understand:

pipeline stages,
execution depth,
transactions,
images,
filtering attributes,
synchronous vs asynchronous execution,
recursion,
security context,
service calls.

If the abstraction makes those concepts invisible, debugging becomes harder rather than easier.

It should not own everything just because it can

In 2026, Microsoft already provides first-party tooling for large parts of the development lifecycle.

For example:

Plug-in project      → pac plugin
Typed model code     → pac modelbuilder
Solution lifecycle   → pac solution
PRT                  → pac tool prt

A framework does not need to reimplement every Power Platform CLI feature.

Sometimes the better design is to integrate with the Microsoft tool instead of competing with it.

Pillaro follows that approach for early-bound generation: its project tooling prepares a local Tools/EarlyBound/ workflow, but the actual generator underneath is Microsoft's pac modelbuilder.

It should not make leaving impossible

A healthy abstraction sits on top of understandable platform concepts.

You should be able to explain what the framework is doing in Dataverse without treating it as magic.

That keeps migration possible and reduces long-term dependency risk.

When Plain SDK is probably the better choice

There are situations where I would deliberately stay with the SDK.

One or two small plug-ins

If the entire solution contains a few simple steps, there may be no recurring cost worth abstracting.

You are learning Dataverse plug-in execution

Learning the raw SDK first is useful.

Understanding IPluginExecutionContext before wrapping it gives you a much better mental model when something eventually goes wrong.

Third-party dependencies are restricted

Some customers or regulated environments do not allow additional runtime libraries without a review process.

The plain SDK may be the simplest acceptable option.

The existing codebase is stable

If a mature project has working deployment, documented conventions and little ongoing development, introducing a framework can create migration cost without enough return.

Your architecture is already standardized internally

A strong engineering team may already have:

a plug-in base,
registration automation,
test infrastructure,
logging,
templates,
CI/CD.

At that point you may already have the useful parts of a framework — just internally.

Replacing them with a public framework is not automatically an improvement.

When a framework becomes easier to justify

The case gets stronger when several of these are true:

many plug-in steps are under active development,
several developers work in the same solution,
deployment spans multiple environments,
registration drift has already caused incidents,
business logic is expected to evolve for years,
automated regression testing matters,
onboarding speed matters,
the same architecture is reused across multiple customer projects.

Notice what is missing from that list:

"The plug-in has a lot of lines of code."

Line count is not the main issue.

Repeated engineering decisions are.

The decision I would make

For a small, isolated plug-in, I would start with the SDK.

For a long-lived solution, I would make one explicit decision early:

Who owns the conventions that the SDK intentionally leaves open?

There are three reasonable answers:

1. The individual developer
2. The team / internal standards
3. A framework

The dangerous answer is:

Nobody — we'll decide separately every time.

That is where accidental architecture starts.

A practical decision checklist

Before adding a framework, ask:

What recurring problem are we solving?
Can Microsoft tooling already solve it?
Can a small internal convention solve it?
Does the framework make deployment more reproducible?
Does it make plug-in behavior easier to understand?
Does it improve testability in the way we actually test?
Will a new developer understand the architecture faster?
Can we still reason about the underlying Dataverse execution model?
What happens if the framework is no longer maintained?
Is the adoption cost lower than the repetition cost over the expected lifetime of the solution?

If those questions have good answers, the abstraction may pay for itself.

If they do not, the SDK is still there — and it is still a perfectly valid choice.

What comes next

In Part 3, I will compare two actively maintained frameworks with very different design centers:

Pillaro and XrmFramework.

Not to pick a winner, but to look at what each one chooses to own: execution structure, typed models, deployment, debugging, testing and developer tooling.

If you want to try the approach on a real project, Pillaro is Apache-2.0 licensed and free for commercial use. The GitHub repository contains the getting-started guide, NuGet packages, templates, deployment documentation and testing stack. It is already used in production, with Seyfor documented as the first production adopter.

Sources

Disclosure: I maintain Pillaro. The goal of this article is not to argue that every Dataverse project needs a framework. It is to make the trade-off explicit.

Moving from spkl to Pillaro: A Practical Migration Guide for Dataverse Plugins

Ján — Wed, 23 Sep 2026 17:38:47 +0000

A practical look at what Pillaro can replace in an existing spkl-based Dataverse plugin project, what changes during migration, and what Pillaro deliberately does not try to replace.

If you have been building Dataverse plugins for a while, there is a good chance you have come across spkl.

For years, spkl solved a very real problem: stop registering and deploying Dataverse plugins manually. Instead of clicking through the Plugin Registration Tool for every environment, developers could describe registration in code and configuration and deploy it repeatedly.

A lot of existing Dataverse solutions still use that model today.

The problem is that spkl is no longer actively evolving with the Dataverse development ecosystem. The main SparkleXrm repository has seen no meaningful spkl development for a long time, while unresolved issues around newer Microsoft tooling and authentication remain open. For example, an incompatibility with a newer Microsoft.CrmSdk.CoreTools version was reported in 2022 and remains open today.

That does not mean every existing spkl project suddenly needs to be rewritten.

If your project is stable, its dependencies are pinned, deployment works, and you are not actively changing the solution, migration may give you very little value.

But if you are maintaining an actively developed Dataverse codebase, upgrading dependencies, introducing automated testing, or trying to make deployment more predictable, you may eventually need a path forward.

That is the problem Pillaro is trying to solve.

Pillaro is listed in Microsoft Learn's Community Tools for Microsoft Dataverse catalog and is also published in Microsoft Marketplace. The Marketplace offer installs the Dataverse-side runtime layer, while the C# framework itself is consumed through NuGet.

These listings provide Microsoft ecosystem discovery and distribution paths, but Pillaro remains a community-maintained framework. Microsoft explicitly states that community tools are supported by their publishers rather than by Microsoft.

Microsoft Learn listing · Microsoft Marketplace

Pillaro is also listed in Microsoft Learn's Community Tools for Microsoft Dataverse catalog. It remains a community-maintained framework rather than a Microsoft-supported product, but its inclusion gives Dataverse developers another official documentation path to discover the project.

Community Tools for Microsoft Dataverse — Microsoft Learn

This is not "spkl vs Pillaro"

Pillaro is not a fork of spkl and it is not trying to recreate every spkl command.

spkl is primarily a deployment task runner around the standard Dataverse development model.

Pillaro is a plugin development framework with deployment and registration built into that model.

There is overlap, especially around plugin registration and deployment, but the scope is different.

The useful question therefore is not:

Which one is better?

It is:

If my project uses spkl today, which parts can Pillaro replace, what will change, and what will I need to handle differently?

That is what this article covers.

What spkl typically does in a Dataverse project

A typical spkl-based plugin project can use spkl for several responsibilities:

deploying plugin assemblies,
defining plugin step registration using [CrmPluginRegistration],
configuring registrations through spkl.json,
registering images and filtering attributes,
reverse-engineering an existing deployment using spkl instrument,
generating early-bound classes,
deploying web resources,
unpacking and packing Dataverse solutions.

That was one of spkl's strengths: a relatively small tool could cover a surprisingly large part of the Dynamics/Dataverse developer workflow.

But those responsibilities do not necessarily need to stay in one tool forever.

Microsoft's own tooling has evolved significantly since spkl was introduced. Today, operations such as solution management and model generation have first-party alternatives in the Power Platform CLI.

Pillaro therefore focuses on the part we believe belongs closest to the plugin code itself:

plugin structure, registration, deployment and testing.

What Pillaro can replace

1. Plugin assembly deployment

spkl: yes
Pillaro: yes

Both approaches can deploy a compiled plugin assembly into Dataverse.

The important difference is what happens around the assembly.

With spkl, deployment tooling discovers plugin registration metadata from your assembly and configuration.

With Pillaro, deployment is part of a framework where the registration declared by the plugin code is treated as the desired state of the environment.

2. Plugin step registration as code

spkl: yes
Pillaro: yes

With spkl you typically define registration using attributes such as:

[CrmPluginRegistration(
    MessageNameEnum.Update,
    "account",
    StageEnum.PostOperation,
    ExecutionModeEnum.Synchronous,
    "name,address1_city",
    "Account updated",
    1,
    IsolationModeEnum.Sandbox)]

Pillaro keeps runtime task registration and deployment metadata separate. Deployment metadata is declared through Register(IPluginRegistration registration) using the fluent registration API:

public override void Register(IPluginRegistration registration)
{
    registration
        .OnUpdate<Account>("00000000-0000-0000-0000-000000000000")
        .PostOperation()
        .Synchronous()
        .WhenChanged(
            Account.Fields.Name,
            Account.Fields.Address1_City);
}

The step ID is part of the registration contract and is required. Filtering attributes are declared with WithFilteringAttributes(...), or its more readable alias WhenChanged(...), rather than being hidden in deployment configuration.

The exact syntax differs from spkl, but the important property is the same: the registration is explicit in source control and can travel through environments with the code.

3. Filtering attributes, images and execution order

spkl: yes
Pillaro: yes

Pillaro registration supports the registration metadata you normally need for Dataverse plugin steps, including:

message,
entity,
pipeline stage,
execution mode,
filtering attributes,
pre-images,
post-images,
execution order / rank.

This means the core plugin-registration responsibility that many teams originally adopted spkl for can move into Pillaro.

4. Removing registrations that no longer exist in code

This is where the approaches start to differ more substantially.

A common problem in Dataverse projects is registration drift.

A step existed six months ago. Someone removed or renamed it in code. The assembly gets redeployed — but the old registration remains in one environment.

Now DEV, TEST and PROD no longer contain the same plugin topology.

Pillaro deployment treats registration in code as authoritative.

If a plugin step was previously deployed by Pillaro and is no longer declared, the deployer can detect the difference and remove the obsolete registration.

The intended model is:

Code registration
       ↓
Desired state
       ↓
Compare with Dataverse
       ↓
Create / update / remove
       ↓
Environment matches code

For us, this was one of the main reasons to build the deployment model in the first place.

What Pillaro adds beyond the spkl workflow

Migration does not have to stop at replacing deployment scripts.

Pillaro also introduces a different way of structuring plugin behavior.

Explicit validation and execution

A recurring problem we saw in larger Dataverse implementations was plugin code where everything gradually accumulated inside Execute:

Execute
 ├─ get context
 ├─ check stage
 ├─ validate data
 ├─ load records
 ├─ apply business rules
 ├─ execute changes
 └─ handle errors

The code works.

Then it grows.

Pillaro uses an explicit task model where validation and execution are separate phases.

Conceptually:

Dataverse event
      ↓
Plugin Task
      ↓
Validate
      ↓
Execute

Validation can fail before the execution phase touches the business operation.

The goal is not abstraction for abstraction's sake. It is to make the execution flow obvious and make individual pieces easier to test.

Integration testing against real Dataverse

Pillaro also includes a separate testing package designed for integration tests against an actual Dataverse environment.

Tests:

prepare test data,
create or update records in Dataverse,
trigger the real deployed plugin,
verify the resulting data or exception,
clean up created test data.

For example:

[Fact]
public void CreateContact_WithoutPostalCode_ShouldFail()
{
    var contact = ContactRepository.GetNew(
        city: "Prague",
        postalCode: null);

    Assert.Throws<InvalidPluginExecutionException>(
        () => TestDataService.CreateTestEntity(contact));
}

This is intentionally not a mocked plugin execution.

Dataverse executes the deployed plugin and the test verifies the real outcome.

That gives teams another step beyond reproducible deployment:

reproducible verification of the deployed behavior.

What Pillaro does NOT replace

This part is important.

spkl does more than plugin deployment, and Pillaro intentionally does not reproduce every one of those features.

Capability	spkl	Pillaro	Recommended direction
Plugin assembly deployment	✅	✅	Pillaro
Plugin step registration as code	✅	✅	Pillaro
Filtering attributes	✅	✅	Pillaro
Pre/post images	✅	✅	Pillaro
Execution order / rank	✅	✅	Pillaro
Remove obsolete plugin steps	Not clearly documented	✅	Pillaro
Validation/execution task model	❌	✅	Pillaro
Integration testing against real Dataverse	❌	✅	Pillaro
Modern Custom API metadata registration	❌	✅ registration	Pillaro
Early-bound model generation	✅	❌ built-in	`pac modelbuilder`
Web resource deployment	✅	❌	Power Platform tooling / CI
Solution pack/unpack	✅	❌	PAC CLI
Reverse-engineer existing plugin registration	✅ `instrument`	❌	Manual inventory before migration

A note on Custom APIs: spkl can register a plugin step against a legacy custom action message, for example through [CrmPluginRegistration("dev1_TestAction", ...)]. That is not the same capability as managing modern customapi / customapirequestparameter metadata. Pillaro's MainOperation() registration addresses the modern Custom API scenario.

There is also no Pillaro equivalent of spkl instrument. If an existing environment contains registrations that are not accurately documented in source control, migration starts with a manual inventory of the deployed state. That limitation is important: Pillaro treats code as the desired state, but it does not automatically reconstruct that code from an unknown Dataverse environment.

This distinction is intentional.

We do not think a modern plugin framework needs to own solution unpacking or model generation when Microsoft already provides dedicated tooling for those jobs.

The migration therefore looks less like:

spkl → Pillaro

and more like:

                 ┌─ plugin architecture
                 ├─ plugin registration
spkl project ────┼─ plugin deployment     → Pillaro
                 ├─ plugin testing
                 │
                 ├─ model generation      → PAC CLI
                 ├─ solution management   → PAC CLI
                 └─ web resources         → existing CI / Power Platform tooling

What about spkl maintenance and compatibility?

This is one of the practical reasons we started looking for a different long-term foundation.

As of September 2026, spkl is not under active feature development.

The SparkleXrm repository still exists and existing projects can continue using it, but the Dataverse platform and Microsoft tooling around it have continued to evolve.

There are unresolved compatibility issues in the repository. One concrete example is issue #461, where upgrading Microsoft.CrmSdk.CoreTools broke spkl early-bound generation. In practice, that means teams cannot assume that newer Microsoft package versions can be adopted independently of spkl; package pinning or workarounds may be required.

The maintenance gap shows up elsewhere as well. Issue #490, opened in July 2025, requests Device Code authentication support for spkl. Issue #491, opened in August 2026, reports get-webresources silently doing nothing and explicitly asks about maintaining the project.

These are not arguments that every existing spkl installation is broken. They are evidence that the tool is no longer keeping pace with the current Dataverse tooling stack in the way an actively maintained dependency normally would.

For a stable legacy project, that may not matter.

For an actively maintained codebase that needs current SDK/tooling packages, modern authentication, or ongoing fixes, it matters a lot more.

What does migration actually look like?

The good news is that moving away from spkl does not necessarily mean rewriting all of your business logic on day one.

We see migration as two separate steps.

Step 1 — Replace registration and deployment

Start by moving the operational responsibility:

spkl attributes / configuration
           ↓
Pillaro registration
           ↓
Pillaro deployment

The first goal is simply to make sure the same plugin assembly and the same logical steps are registered correctly.

At this stage, avoid unnecessary business-logic changes.

A migration is much easier to verify when deployment and architecture are not being rewritten at the same time.

Step 2 — Adopt the task model incrementally

Once deployment is stable, plugin implementations can be moved toward Pillaro tasks.

For example, an existing plugin might contain:

public void Execute(IServiceProvider serviceProvider)
{
    var context = GetContext(serviceProvider);

    if (!context.InputParameters.Contains("Target"))
        return;

    var target = (Entity)context.InputParameters["Target"];

    if (!target.Contains("name"))
        throw new InvalidPluginExecutionException("Name is required.");

    // business logic
}

The responsibility can gradually become:

UpdateAccountTask

Validate
 └─ verify required business conditions

Execute
 └─ perform the business operation

You do not need to refactor every plugin in the same pull request.

For a large solution, incremental migration is usually safer.

When migration probably makes sense

Consider moving away from spkl when several of these are true:

the project is still under active development,
you need to upgrade Dataverse or Microsoft SDK dependencies,
existing spkl dependencies are blocking those upgrades,
plugin registration differs between environments,
developers still need Plugin Registration Tool to understand deployed state,
you want automated cleanup of obsolete registrations,
plugin classes are becoming hard to reason about,
you want integration tests that exercise deployed plugins in Dataverse,
you are standardising CI/CD for multiple Dataverse projects.

In that situation, keeping an unmaintained deployment layer alive can become more expensive than replacing it.

When you should probably stay on spkl

There is no value in migrating simply because a newer tool exists.

If you have:

a mature solution,
pinned dependencies,
reliable deployments,
very little ongoing plugin development,
no registration drift,
and no need for newer tooling,

then leaving the project alone can be the right engineering decision.

Migration itself has a cost and creates risk.

The goal should be to remove a real problem, not to modernise code for appearance's sake.

A practical migration checklist

Before migrating an existing spkl project:

[ ] Inventory all plugin assemblies.
[ ] Export or document all current plugin steps.
[ ] Document filtering attributes.
[ ] Document pre/post images.
[ ] Document execution order.
[ ] Identify configuration values.
[ ] Identify every spkl command currently used in CI/CD.
[ ] Separate plugin-related spkl usage from solution/web-resource tooling.
[ ] Recreate plugin registration in Pillaro.
[ ] Deploy into a non-production Dataverse environment.
[ ] Compare deployed registration with the original environment.
[ ] Add integration tests for critical plugin flows.
[ ] Remove the old spkl deployment only after the new deployment is verified.
[ ] Migrate solution/model-generation responsibilities to PAC CLI where appropriate.

The important part is that spkl removal itself should not be the objective.

The objective is a codebase where:

plugin behavior is understandable,
registration is reproducible,
environments do not silently drift,
deployment works with the modern toolchain,
and critical behavior can be verified automatically.

What comes next

This article focused specifically on teams already using spkl.

The next articles in this series will look at different decisions:

Plain SDK vs a plugin framework — when adding a framework actually pays for itself.
Pillaro and XrmFramework — two actively maintained but very different approaches to structuring Dataverse development.
The Dataverse plugin tooling landscape in 2026 — where the SDK, PAC CLI, deployment tools and frameworks fit together.

If you are currently maintaining a spkl-based project and there is a migration scenario we have not covered here, open an issue or discussion in the Pillaro Dataverse Plugin Framework repository.

We would rather document the migration gap than pretend it does not exist.

Sources

Disclosure: I maintain Pillaro. This article is written for teams evaluating a path away from spkl, not to claim that every existing spkl project should migrate.

Why Dataverse Plug-in Steps Drift — and Why Stable IDs Fix It

Ján — Thu, 10 Sep 2026 13:23:27 +0000

If you have worked on a Dataverse project with more than one developer and more than one environment, you have probably seen this:

A plug-in fires twice. Or three times.

An autonumber skips values.

A validation message appears twice in the same dialog.

You open the Plugin Registration Tool, expand the assembly, and find two steps registered on the same message, the same table, the same stage — one of them created three weeks ago by someone who no longer remembers doing it.

The usual reaction is to delete the extra step and move on.

But the duplicate is not the problem.

It is a symptom of where the registration lives.

Where registration actually lives

A plug-in step is a row in Dataverse.

SdkMessageProcessingStep stores information such as:

message
table
execution stage
execution mode
filtering attributes
execution order
unsecure configuration

Secure configuration is stored separately in SdkMessageProcessingStepSecureConfig, and plug-in images are separate records as well.

None of that is part of the compiled plug-in assembly.

The assembly contains the code.

Dataverse contains the metadata that decides when and how that code executes.

This separation is where drift starts.

Your C# lives in Git, gets code-reviewed, has a history, and is expected to be consistent across environments.

Registration metadata, on the other hand, can become environment state — modified through tools or transported through solutions — and it can diverge from what developers believe should be registered.

Without a single source of truth connecting the two, code and registration drift apart.

How the duplicate actually appears

The mechanics are worth being precise about, because they explain why the problem is so persistent.

When you register a new step through the Plugin Registration Tool, Dataverse creates a new SdkMessageProcessingStep record with its own ID.

If another logically equivalent step is registered separately, it is still a different Dataverse record.

Both are valid.

Both can fire.

Now add multiple environments:

development
test
UAT
production

And multiple ways of getting plug-ins there:

manual registration
solution transport
deployment scripts
different developers doing different things over time

A step may be transported as a solution component while another version of what developers consider the same logical step was created manually.

If those records have different identities, Dataverse does not consider them duplicates.

They are simply two different registered steps with similar configuration.

That distinction is important.

The real problem is identity

The common explanation is that deployment tools should update existing steps instead of creating new ones.

That is only part of the problem.

Dataverse can update an existing component when it knows which component it is updating.

But two registrations with different IDs remain two different registrations, even if they share the same:

message
table
stage
plug-in type
execution mode
filtering attributes

From the platform's perspective, they are still two separate records.

Without a stable identity for the intended step, deployment tooling has no reliable way to say:

This is the step that should already exist.

And that is why duplicate registrations keep coming back.

Things that partially help

There are several approaches that reduce the problem.

Solution-based transport

Add plug-in steps as solution components and move them with the solution.

This works and is the platform-native approach.

But it does not prevent duplicates that already exist in development, and the registration itself is still not particularly convenient to review next to the C# implementation.

The code says what the plug-in does.

The environment still says when it runs.

Configuration-driven deployment

You can describe registrations in deployment configuration and synchronize environments from there.

This improves repeatability and auditability, but the registration still lives somewhere separate from the code it governs.

Attribute-based or declarative deployment tools

Tools such as spkl and XrmFramework have used a declarative approach for years.

The registration is described in source control and deployment tooling synchronizes Dataverse accordingly.

This is the right shape of solution.

And the principle behind it matters more than the specific tool.

The fix is a stable identity declared in code

If a logical plug-in step has a stable identity that lives in source control, deployment can stop being:

Register another step.

and become:

Make the environment match this declaration.

Repeated deployments can then find the registration created previously and update it instead of creating another copy.

That single change has consequences that go far beyond duplicate plug-in steps.

Registration becomes reviewable

Imagine changing a plug-in from:

PreOperation

to:

PostOperation

or adding another filtering attribute.

That can completely change the behavior of the solution.

Yet in many Dataverse projects, that change happens through the Plugin Registration Tool and never appears in a pull request.

When registration metadata lives with the code, the trigger becomes part of the review.

The reviewer no longer sees only:

public void Execute(...)
{
    // business logic
}

They also see when that code is supposed to execute.

That is a much more complete review.

Environments become comparable

A very common Dataverse question is:

Is production registered the same way as test?

Without deterministic deployment, answering that often means opening two environments and comparing registrations manually.

With declarative registration, the intended state already exists in the repository.

Deployment tooling can compare the environment against that state and report the difference.

You are no longer comparing environment A with environment B.

You are comparing both environments with the same source of truth.

Rollback becomes reproducible

When registration is source-controlled, rollback stops being:

Does anyone remember what this step looked like before?

Instead:

revert the declaration
deploy again
restore the previous registration

Code and execution metadata move together.

That is what deterministic deployment should mean.

What this looks like in practice

In the Pillaro Dataverse Plugin Framework, the framework I maintain, plug-in registration metadata is declared directly in the plug-in class.

For example:

public override void Register(IPluginRegistration registration)
{
    registration
        .OnUpdate<Contact>("5056ef4c-0e08-f111-8407-000d3ab261ac")
        .PreOperation()
        .Synchronous()
        .Rank(1)
        .WhenChanged(
            c => c.FirstName,
            c => c.LastName);
}

The explicit identifier represents the identity of the logical Dataverse step.

The same approach is used for plug-in images.

Deployment reads these declarations and builds the desired registration state.

It can then:

update existing steps
create missing steps
synchronize filtering attributes
synchronize images
synchronize execution order
synchronize registration metadata
remove registrations that are no longer declared

The same source of truth is used for local development and automated deployment.

A developer can run the deployment locally while implementing the plug-in.

The same deployment process can run from Azure DevOps.

There is no need to manually recreate registrations in each environment.

The Plugin Registration Tool still has a place

None of this means the Plugin Registration Tool is a bad tool.

It is extremely useful for:

inspecting registrations
troubleshooting
understanding an unfamiliar environment
checking execution configuration

But there is an important distinction:

It is a good place to inspect what is registered.

It is a poor place to decide what should be registered.

That decision belongs in source control.

The part worth taking away

Duplicate plug-in steps are usually treated as an annoying deployment issue.

But the duplicate itself is only the visible symptom.

The deeper problem is that the intended identity and configuration of the step are not part of the same source-controlled definition as the code.

Once registration becomes declarative and each logical step has a stable identity, deployment becomes deterministic.

And once deployment becomes deterministic:

developers stop recreating registrations manually
environments stop drifting
registration changes become reviewable
repeated deployments become predictable
rollback becomes reproducible

If your team is deleting duplicate plug-in steps by hand every few weeks, deleting them is not the fix.

Move the declaration into the repository.

Which tool you use matters much less than making that move.

The Pillaro Dataverse Plugin Framework is open source under Apache-2.0 and free for commercial use, including client projects.

If you prefer another implementation of the same idea, also take a look at spkl and XrmFramework.

The important part is not the framework.

The important part is making plug-in registration deterministic.

DEV Community: Ján

Dataverse Plugin Development in 2026: The Tooling Stack Explained

Start with the platform: the Dataverse plugin SDK

Microsoft now owns much more of the tooling layer

Plugin projects: pac plugin

Registration tooling: PRT still has a job

Typed code generation: pac modelbuilder

Solution lifecycle: pac solution

Native Git integration changes the ALM picture again

Visual Studio is another valid first-party path

The stack by responsibility

Three reasonable project shapes

1. Minimal first-party stack

2. Structured framework stack

3. Existing / legacy tooling stack

Frameworks belong above the generic tooling layer

Where XrmFramework fits

Where Pillaro fits

Where PRT still fits

Where AI-assisted development changes the equation

My default approach for a new Dataverse plugin project in 2026

1. First ask whether you need a plugin

2. Start with current Microsoft tooling

3. Decide how plugin architecture will be standardized

4. Put registration state under control

5. Put solution state under source control

6. Decide what "tested" means

7. Keep the stack replaceable

The series in one picture

Closing thought

Sources

Pillaro and XrmFramework: Two Different Approaches to Dataverse Plugin Development

The short version

XrmFramework's design center: remove Dataverse development friction

Plugin steps are declared in code

Strongly typed models are a major part of the experience

Business logic is organized into services

Custom APIs are first-class

Remote debugging is a differentiator

The tooling surface is broad

Pillaro's design center: make the execution model explicit

A task has an explicit lifecycle

Runtime task registration and deployment registration are separate

Deployment is treated as synchronization

Testing targets real Dataverse

Diagnostics are part of the runtime model

The comparison

The biggest architectural difference

Typed metadata: two valid approaches

XrmFramework

Pillaro

Debugging vs observability

XrmFramework: debug the live execution

Pillaro: make executions inspectable

Testing: simulated isolation vs deployed behavior

Breadth has a cost — and narrowness has a cost

When XrmFramework is a natural fit

When Pillaro is a natural fit

Migration cost matters more than feature tables

My conclusion

What comes next

Sources

Plain SDK vs a Plugin Framework: When Does the Abstraction Pay Off?

TL;DR

What the Plain SDK gives you in 2026

A small plug-in may not need a framework

Where the cost starts to appear

Execution boilerplate

Validation mixed with execution

Registration lives somewhere else

Environment drift

Testing becomes inconsistent

Five signals that an abstraction may start paying for itself

1. You are repeating the same structure

2. Registration is part of delivery risk

3. The project needs repeatable tests

4. More developers need to understand the same codebase

5. The solution will live for years

What a framework should actually buy you

A concrete example: the Pillaro approach

Plugin projects: `pac plugin`

Typed code generation: `pac modelbuilder`

Solution lifecycle: `pac solution`