Documentation:MDriven 7.2

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 +

MDriven 7.2 - end in mind is to modernize and make MDrivenDesigner and MDrivenFramework-for-VisualStudio2022 run .net8 (your apps can already today run .net8)

• This will allow us to solve a ton of GAC related issues
• It will allow us to use BlazorWebView for ViewModel design
• It has to be done soon due to the fact that the clock is ticking

Change drivers and mitigations

When compiling the MDrivenDesigner WPF parts in .net8, we get a conflict for type references and namespaces used in XAML. In order to allow the XAML to stay the same (there is no conditional defines in XAML), we need to switch even the old Framework version to use the Eco.ModelLayer assemblies compiled with .netStandard...

This is relatively safe - since .netStandard works for all versions - and we really do not need a non .netStandard version of things that we have .netStandard versions of.

The Eco.ModelLayer.netstandard assemblies reference the Eco.handles,Eco.Interfaces and Eco.LinqExtender assemblies. We have these in .netStandard as well - so we may as well shift out old Eco.handles,Eco.Interfaces and Eco.LinqExtender to mdriven.handles.netstandard,mdriven.Interfaces.netstandard and mdriven.LinqExtender.netstandard

This will mean that Eco.handles,Eco.Interfaces and Eco.LinqExtender will be pensioned today - and we will only build mdriven.handles.netstandard,mdriven.Interfaces.netstandard and mdriven.LinqExtender.netstandard going forward.

Breaking changes

1. WinForms designer will complain on Winform generated code:

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

2. Another issue is that the IAsyncSupportService had calls for DispatchTaskToMainThread , but Dispatcher is actually a WPF/Windows-only-class. However, the principle of Dispatch is good and practical for a lot.

 /// <summary>

    /// In .netStandard there is no Dispatcher, but when using this from other platforms (WPF) we can inject an eqvivalent valid for that platform

    /// </summary>

    void InjectThePlatformDispatcherEqvivalent(System.ComponentModel.ISynchronizeInvoke platformDispatcherEqvivalent);

The above call has been added to IAsyncSupportService, and the suggested use of it is like this, go like this whenever you turn on asynchandlling:

 EcoServiceHelper.GetAsyncSupportService(_ecospace).TurnOnAsyncHandling();

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

The DispatcherSynchronizeInvoke class is in ECO.WPF (framework) and MDriven.WPF.core (.net8).

We are also dropping WCF as supported communications channel to PMapper - we rely 100% on WebApi.

EnterpriseServices distributed transactions will not be supported in .net6+.

What you need to do

All assemblies that prior used Eco.handles,Eco.Interfaces and Eco.LinqExtender will now need to use mdriven.handles.netstandard,mdriven.Interfaces.netstandard and mdriven.LinqExtender.netstandard

The old assemblies resided in one and the same nuget package https://www.nuget.org/packages/EcoCore

The new assemblies have one Nuget package each:

• https://www.nuget.org/packages/MDriven.Interfaces.netStandard
• https://www.nuget.org/packages/MDriven.Handles.netStandard
• https://www.nuget.org/packages/MDriven.LinqExtender.netStandard

This includes your own components and plugins and everything else. Don't worry - you can stay in .netFramework4.8 if you want. These are all in .netStandard2.0 and that is the shared format between .netFramework4.8 and .net6,8,Core.

What about the rest of the assemblies?

Assemblies like Eco.Persistence, for example, that were included in the old EcoCore package - will possibly still stay in that package but then depend on netStandard versions the mdriven.interfaces etc... There are also newer versions of these assemblies like https://www.nuget.org/packages/MDriven.Persistence.netStandard

The rule is that if your target environment is .net6 or higher you should only have MDriven.*packages and NOT ANY of the old Eco* packages. If you, however, target .netFramework4.7.2 up to 4.8, you will still use mdriven.interfaces.netstandard, mdriven.handles.netstandard , mdriven.linqextender.netstandard, but to get other assemblies (winforms, wpf, mdriven.net.http), you will use the old ones (EcoCore,EcoWinForms,EcoWPF).

GAC - finally we do not need it

If the VS-designtime (that runs net472) loads MDriven.handles from 2 different places, i.e. project assemblies and plugin location - it became difficult to mitigate the 2 versions of MDriven.handles, but we found a solution.

The data for the handles are now serialized and transported between types in .net472 and even between process boundaries for .net6+ (designtoolserver is a separate process created by Visual Studio to hold .net6+ winform designer).