У меня есть несколько DLL-совместимых x86-библиотек C++ Builder, которые используются в тестовой документации x86. TestDll инициализирует внешнее устройство и пытается его подключить (используя сторонние библиотеки DLL). TestDll зарегистрирован и сделан com-visible, чтобы проверить его в Excel тоже. Она вызывается из VBA в Excel и аналогичного кода Visual Basic .Net:Сторонняя DLL работает при вызове из Excel и сбой в случае вызова из VisualBasic/C#
Dim test As New TestDLL.TestDLL.Class1
Dim i As Integer
i = test.Connect()
If i = 111 Then
lbl1.Text = "Connected"
End If
If i = 222 Then
lbl1.Text = "Not connected"
End If
If i = 333 Then
lbl1.Text = "Error!!!"
End If
Ссылка на TestDll добавляется в Excel и код успешно возвращает «Connected». Когда тот же самый код запускался из приложения Windows Forms, он возвращает «Error !!!».
Что я сбила с толку, так это то, что в Visual Basic ссылки на DLL-файлы thidr-party имеют форму: C: \ windows \ assembly \ GAC_MSIL \ Interop.ThirdPartyDll ...... и когда я добавляю ссылка на него в Excel, она имеет форму: C: \ Program Files (x86) \ Common Files \ ThirdParty \ ThirdParty.dll
Я попытался это сделать. Он автоматически добавляет ссылку на GAC. – CheBurek
Вы можете удалить ссылку с GAC, а затем повторите попытку. –
Ну, я удалил сборки из GAC и зарегистрировал только те библиотеки DLL, которые мне нужны (с помощью regsvr32). Excel Показывает в ссылках ссылки на сторонние DLL как ThPart.DLL, ссылки в VB Похоже, Interop.ThPart.DLL. Установка сторонних DLL содержит уже интерпопы, но их длина отличается от длины новых interops в bin-Folder. И снова: в Excel работают сторонние DLL, в VB - нет. – CheBurek