VB6 calling VB.NET calling third party COM dll error

2
votes

I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.

An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.

I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.

Thanks, Chris

1
vb.netcomvb6interopvb6-migration
After some research, I found some potential solutions to try. Here is what I tried from the research, including the results so far. 1. Add the interop dll to the VB6.exe path, which did not work. 2. Register the interop dll to the GAC, which was not recommended, and did not work anyways. 3. Add code to the .NET dll that will force resolving the location of the interop assembly, which did not work either. - Chris Calvert
The most recent thing I found was to run Assembly Binding Log Viewer (fuslogvw.exe from developer command prompt as admin) to log the assembly bindings. There I found that the VB6.exe is looking for the VB.Net dll in its path, which makes no sense since that dll is working just fine in debug with the VB6 project. I tried placing that dll in the VB6.exe directory anyways (to try it out) and then got errors that the VB6 project could no longer find a different VB.Net dll that has been working without issue for years now. - Chris Calvert
I will try to copy all the VB.Net dlls to the VB6.exe directory to see if that might work now. If it does not, I am at a loss as to what to try next. If anyone would like for me to post the assembly log for the binding errors, let me know. - Chris Calvert
Ok, so after placing all my .NET dlls (including interop dlls) into the VB6.exe directory, I still got the error. But this time the assembly binding logs were different. This time it was able to load the assembly without issue, but it was not able to complete the setup of the assembly. Researching this I found that it could be the .NET framework version of the interop assembly, so I loaded it in ILSpy to behold that it was using .NET 4.0, while my dlls are all .NET 2.0 (most of my customers are still on old machines and only have 2.0). - Chris Calvert

1 Answers

5
votes

I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.

The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.

Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.

Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.