0

We have programmed some custom Windows Forms components that use an editor from Eco.Handles.Design.dll to be able to reference a handle (ExpressionHandle or ReferenceHandle) or to be able to enter an OCL expression using an OCL editor during design time of the Windows Forms custom control. The component that defines the custom controls needs a reference to Eco.Handles.Design.dll so that the editors can be used.

As of Visual Studio 2022 the assembly Eco.Handles.Design.dll can only be installed via the VSIX package and the assemblies in the VSIX package have a different build number than the nuget packages that are referenced in the projects.

When I create a neu Windows Form that contains the custom component an the assemblies from the nuget package, the Windows Forms Designer shows following error message:

enter image description here

I assume following: The method "Eco.Handles.ColumnCollection.AddRange" is part of Eco.Handles.dll and Visual Studio 2022 (devenv.exe) tries to call InvokeMember to add a Column to a ColumnCollection. The designer somehow cant find the method in the referenced assemblies.

The only difference to our VS2019 scenario is that there alls assemblies have the same build number.

My questions:

  1. Can the error be caused by the different build numbers of the referenced assemblies. If so, is a redirection to the supplied assemblies possible (maybe via devenv.exe.config)?
  2. Is it possible to get a "Eco.Handles.Design.dll" with a specific build number to see if the build number is the reason?
  3. Is there any way to analyse the problem? Is there a log somewhere that tells the reason why the method was not found?
  4. Any other idea to get the designer up and running again?
Peter Buchmann
  • 85
  • 5

1 Answers1

0

The MDrivenFramework Visual Studio 2022 plugin use the new BuildNumber sequencing where all ECO and MDriven assemblies have version 7.1.0.0 disregarding build time.

Why? What happened to build numbers? Read more on Build numbers here : https://wiki.mdriven.net/index.php/NugetProject

.NET will make types from assemblies with different strong names different - when we switched to use NuGet we must make sure the MDriven Design time can treat the runtime MDriven from your current NuGets and vice verse. To facilitate this all assemblies have the same build number 7.1.0.0 and NuGet is the mechanism to handle version separation.

Hans Karlsen
  • 2,275
  • 1
  • 15
  • 15