Before going nuts about this issue
This page was created by Hans.karlsen@mdriven.net on 2023-07-17. Last edited by Edgar on 2025-01-20.

In visual studio we have MDriven code that makes up the designtime experience. This is the model and the OCL-Editor and the like.

One of the older things of MDriven are the WindowsForms Handles; ExpressionHandle, ReferenceHandle and CursorHandle to mention a few.

These handles connects to the DesignTime code for Visual Studio that we find in Eco.Handles.Design.

We run into a problem when Visual Studio compiles your code and find MDriven assemblies in it - specifically the Eco.Handles.dll. Visual studio will copy that Eco.Handles.dll from your project and put it in a directory like this:

C:\Users\hans\AppData\Local\Microsoft\VisualStudio\17.0_d364b061Exp\ProjectAssemblies\cobgw1bv.p2l01\Eco.Handles.dll

Now whenever your WindowsForms designer code is de-serialized in design time (executed to actually assign properties) - Visual Studio will first look in ProjectAssemblies - and find a copy of Eco.Handles.dll there - it will load this even though we have one loaded from where we installed the MDriven-Extension:

C:\USERS\HANS\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\17.0_D364B061EXP\EXTENSIONS\MDRIVEN AB\MDRIVENFRAMEWORK\7.0.0.14859\Eco.Handles.dll

After this has happened Visual Studio has 2 code-bases for the Handles - one the Plugin uses and one the placed Handles in the WindowsForms form use.

This gives us strange exceptions as

MDriven Chat

How would you like to chat today?

Setting up your conversation…

This may take a few moments