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
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 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 - finally we do not need it
If the VS-designtime (that runs net472) loads MDriven.handles from 2 different places, ie project assemblies and plugin location - it got hard 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 seperate processes created by Visual Studio to hold .net6+ winform designer)