0

I am performing a bit of maintenance on an ancient application written years and years ago in VB6. At some point it was migrated to VB.NET with virtually no changes. I don't know how or why they managed that.

The project in source control contains references to Interop.MSHierarchicalFlexGridLib and AXInterop.MSHierarchicalFlexGridLib with the warnings "<The system cannot find the reference specified>". The project contained over 102 errors (which, if you are new to Visual Studio 2008, is the maximum number of errors displayed in the Error List).

I removed these two broken references and added a reference to the Microsoft Hierarchical Flex Grid 6.0 COM control. This corrected all of the references to MSHierarchicalFlexGridLib.MSHFlexGrid, bringing the number of errors down to 64. The remaining errors are the result of unresolved references to the AxMSHierarchicalFlexGridLib namespace, almost exclusively in Designer code. At first I thought this might just be some Import trickery (renaming the namespace), but the name of the control is also prefixed with "Ax" (AxMSHierarchicalFlexGridLib.AxMSHFlexGrid). I would guess that "Ax" simply stands for "Active X" and refers to the exact same control, but before I go and change 60+ references in largely Designer code, I'd like to learn a bit more. My Google-fu has so far failed me.

Questions:

  • Is AxMSHierarchicalFlexGridLib.AxMSHFlexGrid the same as MSHierarchicalFlexGridLib.MSHFlexGrid?

  • If it is the same, why did the Designer change the name, and is it safe to simply find-replace all references to the renamed namespace? (Also, where did the second reference to AXInterop.MSHierarchicalFlexGridLib come from?)

  • If it's not the same, what's the name of the COM control I'm missing?

Another bonus question:

The project in source control seems to contain references to the interops only, not to the COM objects. I can believe that someone who didn't know what they were doing managed to stumble their way into something that "worked", but just in case... is there any way that Visual Studio's many automated wizards, tools, etc, may have been involved? I want to ensure that this scenario is not repeated.

Thanks

P.S. I would just rewrite this project from scratch, but the frmMain code file (I daren't say "Class") alone contains nearly 17,000 lines, so the undertaking would require more hours than I'm permitted to spend.

JDB
  • 25,172
  • 5
  • 72
  • 123

1 Answers1

2

As commented, assemblies whose name start with AxInterop are normally auto-generated by the Aximp.exe tool. Which creates a control derived from Winform's AxHost class and supports dropping an ActiveX control on a form.

Given the age of the MSHFlexGrid, a VB6 control, you probably want to check-in the DLL into source control so you won't lose it again.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • It's common for developers to put these kinds of files in the bin folder, which is generally not checked into source control (this is what happened to the project in question). I've placed the dll's in a folder named "Include" within the project directory, checked the files into source control and added project references to them via "Browse" (Copy Local set to True). This will ensure the dll's travel with the project, but does not require that the bin folder be checked into source control. – JDB Aug 28 '12 at 19:43