You can use the MDriven Visual Studio extension with Visual Studio 2026 and current 2026 builds of Visual Studio 2022; this page explains the design-time changes, what they mean for your projects, and how to avoid package-related mismatches.
The same extension build supports Visual Studio 2022 and Visual Studio 2026 side by side. Follow MDriven Framework Visual Studio installation for installation and to find the installed extension path in Tools/MDriven/About.
What you need to do
- Use current MDriven NuGet packages in your project. For the November 2024 and later package guidance, use MDriven packages such as
MDriven.InterfacesandMDriven.Handles, rather than the older Eco packages where the current package guidance says to replace them. See Documentation:MDriven 7.2. - Keep the MDriven extension and your project packages current when you update Visual Studio.
- When you edit OCL in a WinForms handle, keep the Modlr model open. The OCL editor now obtains model metadata directly from that model.
- Configure the runtime EcoSpace to include every package defined by the model. Do not rely on a package subset unless you have verified that the runtime type system contains every class and association used at design time.
For installation procedures, see Documentation:MDriven Framework Visual Studio installation. For .NET target and package guidance, see Documentation:Dotnet core and Documentation:MDriven 7.2.
What changed
MDriven separates the assemblies used by your application at runtime from assemblies used by the Visual Studio extension at design time. This separation removes a long-standing class of Visual Studio load-context conflicts.
A load context is the assembly-loading environment in which Visual Studio loads a DLL. Two assemblies with the same name can be loaded from different locations. In that case, .NET can treat their types as different types even when the assembly files otherwise appear equivalent.
For example, if Visual Studio loads MDriven.Handles from your project's NuGet output and also loads MDriven.Handles from the extension directory, an object created from one copy cannot reliably be used as an object from the other copy. Earlier symptoms included reflection failures, designer crashes, and generated-code errors such as a missing AddRange method.
Separate identities for runtime and design-time assemblies
The extension design-time assemblies and the runtime/NuGet assemblies now have different signing identities.
| Assembly role | Public key token | Purpose |
|---|---|---|
| Runtime and NuGet assemblies | 46a833be9e90de8c
|
Assemblies loaded by your project and application. |
| Design-time assemblies in the Visual Studio extension | 8284d47cc38744ec
|
Assemblies loaded by the MDriven Visual Studio designers. |
The different identities ensure that Visual Studio does not merge or cross-bind the project and extension assembly worlds. If you see an assembly signed with the design-time public key token, it is intentional and is required for design-time stability.
DTO boundary between the project and the extension
A DTO (data transfer object) is a simple serialized data representation. MDriven designers now exchange DTOs across the project-to-extension boundary instead of exchanging project-loaded objects directly.
The flow is:
- The project extracts the data needed by the designer into DTOs.
- The Visual Studio designer works with those DTOs in its own assembly context.
- The designer returns DTOs after an edit.
- The project rehydrates the DTOs into its own runtime objects.
This avoids passing a type loaded by the project into code loaded by the extension. The approach was already required for .NET 6+ WinForms design, where Visual Studio uses a separate design-tool process. It is now used consistently for all designers, including .NET Framework 4.8 and legacy designers.
Why this was necessary
Earlier Visual Studio integration depended on the Global Assembly Cache (GAC). The GAC made one machine-wide assembly version available, so Visual Studio and the project commonly loaded the same physical assembly. That reduced visible load-context conflicts, but it also prevented normal per-project package versioning and made side-by-side testing difficult.
With NuGet-based delivery, Visual Studio can encounter assemblies both from the project and from the installed extension. The GAC no longer masked that situation. The new assembly identities and DTO boundary solve the underlying problem without returning to a GAC dependency.
For background on the older failure mode and its symptoms, see Documentation:Before going nuts about this issue. For the related move away from GAC and the serialized handle-data approach, see Documentation:MDriven 7.2.
OCL editor: use the open Modlr model
The OCL editor for EcoHandles in WinForms now gets its type information directly from the Modlr model rather than by reflecting generated code and extracting IEcoTypeSystem from a compiled EcoSpace.
This means that you can update OCL types without a code-generation and compilation cycle.
Work with updated model types
- Open the Modlr model in MDriven Designer.
- Make the model change, such as adding a class, attribute, or association.
- Save the model.
- Return to the OCL editor while the Modlr model remains open.
- Use the updated model types in your OCL expression.
For example, after you add an association to the model and save it, the OCL editor can use that association without first generating and compiling the project.
Requirement: keep the model open
The Modlr model must be open while you work in the OCL editor. The editor uses the open model to obtain the current type system.
Package configuration warning
The Modlr model type system includes all packages defined in the model. A runtime EcoSpace can, however, be configured to use only a subset of those packages. This creates a design-time/runtime mismatch: OCL can recognize a class or association from the model while the runtime EcoSpace does not include it.
Use all model packages in the EcoSpace. This keeps the model, OCL editor, and runtime type systems aligned.
| Configuration | Result |
|---|---|
| EcoSpace includes all packages defined by the model | The OCL editor and runtime use the same classes and associations. |
| EcoSpace uses only a subset of model packages | Design-time expressions can refer to model elements that are absent at runtime, causing confusing missing-type or missing-association behavior. |
For example, if the model defines packages Sales and Support, and an OCL expression refers to a Support association, a runtime EcoSpace configured with only Sales cannot provide the same type system that the editor used.
Upgrade and troubleshooting checklist
- Install or update the extension according to Documentation:MDriven Framework Visual Studio installation.
- Use the current package set described in Documentation:MDriven 7.2.
- For .NET 6 or later, use MDriven packages rather than old Eco packages as described in Documentation:MDriven 7.2.
- Keep the Modlr model open when editing OCL in WinForms handles.
- Include all model packages in the runtime EcoSpace.
- If generated WinForms code contains
new IColumn[]in anAddRangecall, apply the documentedAbstractColumn[]change in Documentation:MDriven 7.2. - If an existing solution still shows an assembly-loading or designer issue, review Documentation:Before going nuts about this issue before applying older GAC-based workarounds.