You can diagnose and resolve Windows Forms designer assembly conflicts in MDriven Designer and Visual Studio, especially errors involving Handles types or generated .Designer.cs code.
Start with the current solution
For current MDriven versions, use the current package and generated-code guidance before trying historical workarounds.
- Update to a current MDriven build. Visual Studio 2026 support documents the changes made to manage the underlying design-time assembly-loading issue.
- In November 2024 builds and later, reference MDriven packages such as
MDriven.InterfacesandMDriven.Handles. Do not referenceEcoCoreor other non-MDriven package names for this purpose. - Check generated Windows Forms designer code. Where the generated code uses:
AddRange(new IColumn[] ...)- change it to:
AddRange(new AbstractColumn[] ...)
- Close and restart Visual Studio after changing packages or generated designer code, then reopen the form in the Windows Forms designer.
For example, if opening a form reports that Eco.Handles.ExpressionHandle cannot be converted to another Handles type, first verify that the project uses MDriven packages only and then check the AddRange call in its .Designer.cs file.
Recognize this issue
This issue affects the Visual Studio Windows Forms design-time environment. It can produce errors that appear impossible because the type names in the message are identical.
Typical symptoms include:
Object of type 'Eco.Handles.ExpressionHandle' cannot be converted to type 'Eco.Handles.ElementHandle'.Method 'Eco.Handles.ColumnCollection.AddRange' not found.- Errors that occur only sometimes, or change after reopening a form or restarting Visual Studio.
These symptoms are not, by themselves, evidence of an error in your model, OCL, or application logic. They can indicate that Visual Studio loaded assemblies from different locations into its design-time processes.
Why identical type names can fail
MDriven has Windows Forms Handles such as ExpressionHandle, ReferenceHandle, and CursorHandle. Older configurations connected these runtime Handles to Visual Studio design-time code through Eco.Handles.Design.
Visual Studio can copy assemblies referenced by a project into a per-project cache, commonly under a path resembling:
C:\Users\<user>\AppData\Local\Microsoft\VisualStudio\<instance>\ProjectAssemblies\<cache>\Eco.Handles.dll
At the same time, the MDriven Visual Studio extension has assemblies in its extension installation directory. If the Windows Forms designer loads one copy while the extension uses another, the two assemblies can define types with the same full name but from different code bases. Visual Studio then treats those types as different types.
Load order made the older problem intermittent. If the Windows Forms designer loaded first, you could get one set of failures; if the MDriven extension loaded first, you could get another.
The Visual Studio 2026 work separates the MDriven extension-side assemblies from the assemblies used by your project through changed strong-name signing. The extension uses the version installed for the designer, while the project uses the assemblies supplied by its MDriven packages. This avoids the earlier collision between project and extension assemblies. For background and rationale, watch the January 2026 walkthrough.
Troubleshooting checklist
Use this order when a Windows Forms form cannot be opened or shows one of the errors above.
| Step | What to check | Expected result |
|---|---|---|
| 1 | Confirm that the failure occurs in the Windows Forms designer, not only when the application runs. | You are investigating a design-time assembly issue rather than a runtime defect. |
| 2 | Update to a current MDriven build and review Visual Studio 2026 support. | The current extension-side assembly separation is in use. |
| 3 | Review project package references. Use MDriven.Interfaces, MDriven.Handles, and other MDriven packages required by the project; remove the older non-MDriven references described above.
|
The project does not bring the older package set into the designer path. |
| 4 | Inspect the affected form's .Designer.cs file and change new IColumn[] to new AbstractColumn[] in the stated AddRange call.
|
Generated initialization code matches the current Handles API expectation. |
| 5 | Restart Visual Studio and reopen the form. | Visual Studio starts a new design-time session with the corrected references. |
Do not diagnose this issue by changing unrelated application behavior. For example, MDrivenServer evolve recovery, WCF tracing, and external-login recovery address separate problems.
Historical GAC workaround
The remainder of this section explains the older workaround for legacy installations that load Eco.Handles.dll from both the Visual Studio extension and Visual Studio's ProjectAssemblies cache.
The Global Assembly Cache (GAC) could take precedence over the project-assembly cache, causing Visual Studio to load the GAC copy of Eco.Handles.dll. This was used to avoid the duplicate-code-base situation.
This workaround has important limitations:
- A VSIX installation cannot install assemblies into the GAC.
- A GAC assembly also takes precedence over assemblies in the application's bin directory.
- If your application uses a different NuGet version, the GAC version can be loaded instead. In a legacy setup, the MDriven extension and relevant packages therefore needed matching versions.
Use the current package guidance and Visual Studio 2026 support first. Do not add a GAC assembly as the first response to a current designer problem.
Install Eco.Handles in the GAC for a legacy setup
If you have confirmed that you are maintaining a legacy setup that requires this workaround:
- Open the MDriven About form in Visual Studio.
- Copy the command shown for the
Gacutil /ioption. - Close the About form.
- Open View > Terminal.
- Paste the copied command and execute it.
- Restart Visual Studio.
Remove Eco.Handles from the GAC
- Open the MDriven About form in Visual Studio.
- Copy the command shown for the
Gacutil /uoption. - Close the About form.
- Open View > Terminal.
- Paste the copied
/ucommand and execute it. - Restart Visual Studio.
The removal command must use /u; do not paste the install command (/i) when you intend to remove the assembly.