Cannot hide anything from you, Noxe)CompositeObjectSpace and NonPersistentObjectAdapter are not yet complete, I will comment on this next week when I am back.
We cannot yet avoid CreateObjectSpace(Type) because: 1. not all operations are propagated to additional object spaces, only in known scenarios (probably it is temporary). 2. it is important to keep the order of operations, e.g. CommitChanges first commits additional object spaces and then commits the main object space (when no errors).
understand Dennis - since we are migrating more and more classes now we hit several places where we have a mixed scenario. the typical one is we create a nonpersistent objectspace and show and view - works perfect since there is an additional xpobjectspace for persistent types
@noxe , specially for you I wanted to share a solution that I was "smoking" over the weekend and which you can try even with the existing v20.2.2 (Beta) and .NET 5.0 RC2:
The idea is to modify the "c:\Program Files (x86)\DevExpress 20.2\Components\Tools\eXpressAppFrameworkNetCore\Model Editor\DevExpress.ExpressApp.Design.ModelEditorServer.NetCore.v20.2.runtimeconfig.json" file as follows:
These crazy versions come from "dotnet --info". For more information on this magic, see https://gist.github.com/natemcmaster/0bdee16450f8ec1823f2c11af880ceeb and https://github.com/dotnet/designs/blob/main/accepted/2019/runtime-binding.md. I would not want to publish this solution yet, because we have not researched all its consequences. For instance, if a developer has only older (v3.0) dependencies - the .NET 5.0 runtime may fail to load them...Once we finish our tests, we will likely specify multiple shared frameworks in the DevExpress.ExpressApp.Design.ModelEditorServer.NetCore.v20.2.CSPROJ so that developers do not need to touch anything.