Documentation:MDriven 7.2

MDriven 7.2

This page was created by Hans.karlsen on 2024-10-04. Last edited by Wikiadmin on 2026-09-12.

You can use this page to prepare MDriven Framework applications, components, and plugins for the MDriven 7.2 assembly transition, whether you target .NET Framework 4.7.2–4.8 or .NET 6 and later.

A recorded session provides a walkthrough of these changes: There is a Wednesday session discussing the changes done with MDriven 7.2: Wednesday with MDriven - walkthrough of the MDriven 7.2 updates that works well with .net6 +

What changes in MDriven 7.2

MDriven 7.2 begins the transition of MDriven Designer and MDriven Framework for Visual Studio 2022 toward .NET 8. Your applications can already target .NET 8; this change modernizes the supporting assemblies and reduces Global Assembly Cache (GAC) issues.

The central change is that the shared model-layer assemblies move to .NET Standard 2.0. .NET Standard 2.0 is the shared target used by .NET Framework 4.8 and .NET 6, .NET 8, and later .NET implementations.

This transition is required because the MDriven Designer WPF code must compile for .NET 8 while retaining the same XAML. XAML does not support conditional compilation directives, so the model-layer type references must be consistent across the supported targets.

Upgrade your assemblies

Replace references to the retired assemblies with the corresponding .NET Standard assemblies. Do this in your application projects and in all custom components, plugins, and other assemblies that reference these types.

Retired assembly	Replacement assembly	NuGet package
`Eco.Handles`	`MDriven.Handles.netStandard`	MDriven.Handles.netStandard
`Eco.Interfaces`	`MDriven.Interfaces.netStandard`	MDriven.Interfaces.netStandard
`Eco.LinqExtender`	`MDriven.LinqExtender.netStandard`	MDriven.LinqExtender.netStandard

The old Eco.Handles, Eco.Interfaces, and Eco.LinqExtender assemblies are being pensioned. Going forward, use the three MDriven.*.netStandard assemblies instead.

Upgrade procedure

Inventory every project that uses Eco.Handles, Eco.Interfaces, or Eco.LinqExtender. Include application projects, shared libraries, custom controls, plugins, and generated-code projects.
Remove the old assembly or package references that supply those three assemblies. They were previously available together through EcoCore.
Add the matching MDriven.*.netStandard NuGet packages from the table above.
Update code where the breaking changes described below apply.
Rebuild every project and test design-time behavior as well as runtime behavior. A plugin that compiles separately must also use the replacement assemblies.

For example, if a custom plugin references Eco.Interfaces and Eco.Handles, reference MDriven.Interfaces.netStandard and MDriven.Handles.netStandard in that plugin before deploying it with the application.

Choose packages by target framework

Use the following rule when selecting remaining MDriven and ECO packages.

Application target	Required rule	Example
.NET 6 or later	Use only `MDriven.` packages. Do not include old `Eco` packages.	Use the .NET Standard replacement packages and newer MDriven packages such as MDriven.Persistence.netStandard where applicable.
.NET Framework 4.7.2 through 4.8	Use the three `MDriven.*.netStandard` replacement packages for interfaces, handles, and LINQ extender. Continue to use the older ECO packages for other framework-specific assemblies where required.	Use `EcoCore`, `EcoWinForms`, or `EcoWPF` for applicable framework-specific assemblies, together with the replacement .NET Standard packages.

Some assemblies that were included in EcoCore, such as Eco.Persistence, may remain in that package and depend on the new .NET Standard assemblies. Newer .NET Standard versions also exist for some assemblies. Select packages according to your target framework; do not mix old Eco* packages into a .NET 6 or later application.

Breaking changes

WinForms generated code uses AbstractColumn

The WinForms Designer may report an error in generated code that adds expression-handle columns. Change the array element type from Eco.Handles.IColumn to Eco.Handles.AbstractColumn.

Replace:

expressionHandle1.Columns.AddRange(new Eco.Handles.IColumn[] { oclColumn1, oclColumn2});

With:

expressionHandle1.Columns.AddRange(new Eco.Handles.AbstractColumn[] { oclColumn1, oclColumn2});

Inject a dispatcher equivalent when enabling asynchronous handling

IAsyncSupportService supports dispatching work to the main thread. A WPF Dispatcher is a Windows-specific type and is not available in .NET Standard. Therefore, when you enable asynchronous handling, inject the platform-specific equivalent through ISynchronizeInvoke.

IAsyncSupportService now includes:

/// <summary>
/// In .NET Standard there is no Dispatcher, but when using this from other
/// platforms, such as WPF, an equivalent valid for that platform can be injected.
/// </summary>
void InjectThePlatformDispatcherEqvivalent(
    System.ComponentModel.ISynchronizeInvoke platformDispatcherEqvivalent);

In a WPF application, enable asynchronous handling and inject the current WPF dispatcher together:

EcoServiceHelper.GetAsyncSupportService(_ecospace).TurnOnAsyncHandling();
EcoServiceHelper.GetAsyncSupportService(_ecospace)
    .InjectThePlatformDispatcherEqvivalent(
        new DispatcherSynchronizeInvoke(
            System.Windows.Threading.Dispatcher.CurrentDispatcher));

DispatcherSynchronizeInvoke is provided by ECO.WPF for .NET Framework and by MDriven.WPF.core for .NET 8. Use an equivalent appropriate to the UI platform when your application is not WPF.

Unsupported communication and transaction options

MDriven 7.2 removes support for the following options:

WCF is no longer a supported communication channel to PMapper. Use WebApi.
EnterpriseServices distributed transactions are not supported in .NET 6 and later.

Review integrations before upgrading. For example, an application that communicates with PMapper through WCF must move that communication to WebApi as part of its upgrade.

Design-time loading and the GAC

This transition removes the need to rely on the GAC for this scenario. Visual Studio design time runs on .NET Framework 4.7.2, while newer WinForms design tooling for .NET 6 and later can run in a separate DesignToolServer process. Loading MDriven.Handles from both project assemblies and a plugin location previously created difficult version-conflict scenarios.

MDriven now serializes handle data when it moves between .NET Framework 4.7.2 types and across process boundaries for .NET 6 and later design tooling. This mitigates the two-version handle-loading issue without a GAC dependency.

Checklist

Replace all uses of Eco.Handles, Eco.Interfaces, and Eco.LinqExtender with their MDriven..netStandard replacements.

Update all custom components and plugins, not only the main application.

For .NET 6 or later, remove old Eco packages and use only MDriven.* packages.

Correct generated WinForms column-array declarations to use AbstractColumn.
When enabling asynchronous handling, inject the platform dispatcher equivalent.
Replace PMapper WCF communication with WebApi.
Verify that your .NET 6 or later application does not depend on EnterpriseServices distributed transactions.

Contents