OK, this is a shot in the dark as I'm at my wits end. I have two third-party DLLs that work great in VB6, but not so much in VB.NET or C#.
In VB6, the below works just fine:
Dim oApplication As Object
Dim oSession As Object
Dim vRetCode As Variant
Set oApplication = CreateObject("OAPPLICA.OAPPLICA")
Set oSession = CreateObject("OSESSION.OSESSION")
oApplication.PROGRAMDRIVE = "\\dev\data\"
oApplication.WORKAREADRIVE = "\\dev\data\workarea\"
oApplication.DATADRIVE = "\\dev\data\"
oApplication.IMAGEDRIVE = "\\dev\data\image\"
oSession.MYAPPLICATION = oApplication
vRetCode = oSession.LOGIN("USER1", "PASSWORD1") 'Returns zero if successful
MsgBox (vRetCode)
When I run this exact same set of code in VB.NET I get "Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))" on the "oSession.MYAPPLICATION = oApplication" line.
I've tried doing early binding as well in both VB.NET and C#, but eventually end up with the same error on a different line. I get the same error for the below on the "oApplication.set_PROGRAMDRIVE("\\dev\lifepro\data\");" line.
private OAPPLICA.OAPPLICA oApplication = new OAPPLICA.OAPPLICA();
private OSESSION.OSESSION oSession = new OSESSION.OSESSION();
Int64 iReturnCode;
oApplication.set_PROGRAMDRIVE("\\\\dev\\data\\");
oApplication.set_WORKAREADRIVE("\\\\dev\\data\\workarea\\");
oApplication.set_DATADRIVE("\\\\dev\\data\\");
oApplication.set_IMAGEDRIVE("\\\\dev\\data\\image");
m_oSession.set_MYAPPLICATION(m_oApplication);
iReturnCode = Convert.ToInt64(m_oSession.LOGIN("USER1", "PASSWORD1"));
As stated earlier, the two DLLs (OAPPLICA.dll and OSESSION.dll) are third-party and allow an entry point into a third-party legacy system. Since it's legacy I don't have access to the third-party anymore, I've just been tasked with trying to prototype converting an existing Windows VB6 application into an .NET web application. My hunch is .NET is having an issue interpreting the interop DLL for the two COM objects, but I have been unable to find anything to point me in a direction.
My guess is that this code would run fine in a WinForms app, have you tried that?
VB6, and most COM components designed for use with VB6, are going to require you to run on an STA thread to work properly. Your web code is likely running on at MTA thread.
Finally got it. For some reason .NET interprets the properties as read-only at run-time (for both C# an VB.NET and for both web and windows), even though there are get and set options at design-time. VB6 interprets the properties as get and set at both run-time and design-time, so you can imagine my confusion. I've never come across anything like this before. Anyway, I started out putting a VB6 wrapper around the third-party DLLs, and then had .NET reference the VB6 wrapper DLL. Worked great and allowed me to continue development, but still wanted to eliminate the extra VB6 layer. One of our COBOL developers was eventually able to mimic/rewrite the legacy DLLs. I hate losing time on crap like this, but I'm glad it's done.
If @tcarvin is correct, and he probably is, you can force an ASP.net app to be STA by using an "AspCompat=true" page directive - msdn.microsoft.com/en-us/library/zwk9h2kb.aspx
User contributions licensed under CC BY-SA 3.0