There is a Wednesday session discussing the changes done with MDriven 7.2: https://youtu.be/Myliyxd4NLw

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 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 in 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

One gotcha 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 has 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.Persitence for example that was included in the old EcoCore package - will possibly still stay in that package but then depend on netStandard versions the mdriven.interfaces etc... There is also newer versions of these assemblies like https://www.nuget.org/packages/MDriven.Persistence.netStandard

GAC - why do we still need it

If the VS-designtime (that runs net472) loads MDriven.handles from 2 different places, ie project assemblies and plugin location - it gets impossible to mitigate the 2 versions of MDriven.handles.

We can easily discover the issue like this:

      this.Owner = columnCollection as ColumnCollection;
     if (columnCollection != null && (columnCollection as ColumnCollection) == null)
      {
        throw new Exception("VS has loaded MDriven.handles from 2 different places and this will confuse it enough to be unable to help you\r\n" +
          columnCollection.GetType().Assembly.CodeBase + "\r\n" +
          typeof(ColumnCollection).Assembly.CodeBase + "\r\n\r\n" +
          "Best solution to this is to add both MDriven.interfaces and MDriven.handles to the GAC (tools/MDriven and button GAC-Verify-and-fix), and restart VS");
      }