Hans Karlsen (talk | contribs) No edit summary |
Hans Karlsen (talk | contribs) No edit summary |
||
| Line 9: | Line 9: | ||
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: | 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 | 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 | After this has happened Visual Studio has 2 code-bases for the Handles - one that the Plugin uses and one that the WindowsForms de-serialized from. | ||
This gives us strange exceptions as: | This gives us strange exceptions as: | ||
| Line 18: | Line 18: | ||
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. | 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 | ...it turns out that no matter what probing path we put eco.handles.dll in we cannot jump in front the projectassemblies path... | ||
...except | ...except when we put the assembly in the GAC - the GAC beats everything, including the projectassemblies... | ||
...Why is GAC not perfect then: | ...Why is GAC not perfect then: | ||
Revision as of 16:39, 17 July 2023
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 that the Plugin uses and one that the WindowsForms de-serialized from.
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 what probing path we put eco.handles.dll in we cannot jump in front the projectassemblies path...
...except when we put the assembly in the GAC - the GAC beats everything, including the projectassemblies...
...Why is GAC not perfect then:
- The VSIX installation is not allowed to put things into the GAC,
- GAC will also trump your bin catalog when executing your app (so if you use other version from nuget - GAC will win).
- Due to point 2 it becomes important that your MDrivenExtension has the same version as your Nuget packages (EcoCore) - or you may run on other code than you think