This article describes a problem you might have to face when converting a VB6 project that references a .NET DLL.
Admittedly, this scenario is quite rare, but it is reasonable nevertheless. For example, you might have a VB6 app that has been extended in recent years to leverage some features offered by the .NET Framework – for example, the ability to consume Web services.
Another relatively common case of a VB6 application that references a .NET DLL may occur while migrating a multi-project VB6 application to .NET, In this case, you tipically begin the migration process by converting the “core” DLLs to .NET first and then converting the client VB6 apps that reference the core DLLs. To ensure that the converted core DLL works correctly after the conversion to .NET you might modify the client VB6 projects so that they reference the .NET DLL instead of the original COM DLL.
Regardless of the reason why a given VB6 project has a .NET DLL among its references, you might find that VB Migration Partner crashes when attempting to migrate such a project to .NET and displays a message box with the following message:
A critical error occurred while generating .NET code.
See error details in file C:\VBMigrationPartner_ErrorLog.txt.
If you open the VBMigrationPartner_ErrorLog.txt file you should read something similar to the following text:
System.IO.FileNotFoundException: Could not load file or assembly 'referencedDll, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find
the file specified.
File name: 'referencedDll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at System.Signature._GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig,
IntPtr fieldHandle, IntPtr methodHandle, IntPtr declaringTypeHandle)
at System.Signature.GetSignature(SignatureStruct& signature, Void* pCorSig, Int32 cCorSig,
RuntimeFieldHandle fieldHandle, RuntimeMethodHandle methodHandle,
RuntimeTypeHandle declaringTypeHandle)
at System.Signature..ctor(Void* pCorSig, Int32 cCorSig, RuntimeTypeHandle declaringTypeHandle)
at System.Reflection.RuntimePropertyInfo.get_Signature()
at System.Reflection.RuntimePropertyInfo.get_PropertyType()
at CodeArchitects.VBMigrationEngine.VBSymbol.CreateChildSymbols(Type ty,
Regex reInheritedMembers, String defaultMemberName)
at CodeArchitects.VBMigrationEngine.VBProjectReference.CreateAddTypeSymbol(Type ty)
at CodeArchitects.VBMigrationEngine.VBProjectReference.CreateSymbols()
at CodeArchitects.VBMigrationEngine.VBProject.CreateProjectReferenceSymbols()
at CodeArchitects.VBMigrationEngine.VBSolution.ConvertCore(Assembly asm)
at CodeArchitects.VBMigrationEngine.VBSolution.Convert()
at VBMigrationPartner.MainDialog.ConvertSolution()
This error occurs when the referenced .NET DLL in turn references another .NET DLL, and VB Migration Partner is unable to locate the latter DLL. The file name referencedDLL in previous error message is the actual name of the .NET DLL that VB Migration Partner failed to locate.
Let’s make a practical example: say that your VB6 project references a .NET DLL named MainLibrary that contains the following method:
Sub MyMethod(ByVal x As Widget)
…
End Sub
where the Widget class is defined in another .NET DLL named SecondaryLibrary. If VB Migration Partner fails to locate the SecondaryLibrary.DLL file than a fatal error occurs during the migration.
Once you understand what the cause is, fixing this problem is quite easy and requires that you add two project-level pragmas to the *.pragmas file related to the project being migrated. Assuming the that SecondaryLibrary.dll file is located in the c:\mydlls folder, these are the necessary pragmas:
Alternatively, you can omit the AddLibraryPath pragma and use only the AddReference pragma if you copy the SecondaryLibrary.dll file in VB MigrationPartner’s installation folder.