Documentation:Before going nuts about this issue

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:

Object of type 'Eco.Handles.ExpressionHandle' cannot be converted to type 'Eco.Handles.ElementHandle'.
Method 'Eco.Handles.ColumnCollection.AddRange' not found.

...these exceptions does not make logical sense until one understands that Visual Studio has mixed the code bases from two different places. Our MDriven extension installation , and your ProjectAssemblies.

To stop visual studio from doing this mistake we must ensure that it finds the Eco.Handles.dll from the extension and do not load the Eco.Handles.dll from ProjectFiles.

...it turns out that no matter in what probing path we but eco.handles.dll we cannot jump in front the projectassemblies path...

...except in we put the assembly in the GAC - the GAC beats everything, including the projectassemblies...

...Why is GAC not perfect then: 1. The VSIX installation is not allowed to put things into the GAC, 2. GAC will also trump your bin catalog when executing your app.