dotnet interop: Hi all,

We have a com dll that was written in vb6. We registered the dll on
TESTSERVER1 (x86) using regsvr32 and then used tlbimp w/ net 1.1 to create a
proxy stub. We then called the proxy stub from a asp.net web service and all
worked well.

We now setup a x64 server TESTSERVER2. Registered the com dll using
C:\WINDOWS\SysWOW64\regsvr32. When then used tlbimp from .net 2.0 x64 sdk
and created a proxy stub for the com dll. We then tried to test the asp.net
web service and it failed with the following error:-

System.Web.Services.Protocols.SoapException: Server was unable to process
request. ---> System.Runtime.InteropServices.COMException (0x80040154):
Retrieving the COM class factory for component with CLSID
{53F83BFB-092B-4602-AEB8-98816AA23E29} failed due to the following error:
80040154. at SterlingService.GetSoftwareActivationKey(Int32 locationid,
Single prodversion) in E:\IIS\Website
Files\soa.test.appone.local\Services\App_Code\Services.vb:line 407 --- End
of inner exception stack trace ---


Any ideas?

[quoted text, click to view]

Are you trying to use the library in-process or out-of-process?
AFAIK you can only use WOW64 to run entire processes in 32-bit
emulation, so if by x64 server you mean that you are actually
running a 64 bit process, then you can't use a 32-bit library
in-process. You would need a 64-bit COM library for this, but

Hi,

Based on my research here is a link may be related with your issue.
VB6 Library import / tlbimp problem on x64
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=706695&SiteID=1

You may try to compile the VB6 in x64 platform so that it will run in the
real x64 process and then use .NET 2.0 to call it.

You may have a try and let me know the result.

Based on my research the error code means "Class not registered", so you
may try to make a test if a common VB6/C++ running in 64bit environment
will call the VB6 COM corrently.


Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

So what are my options here? Continue to run the host process (Web Service)
in 32 bit mode?


[quoted text, click to view]

[quoted text, click to view]

Either that or invest effort to migrate the application to 64 bit,
getting rid of 32-bit dependencies by porting or reimplenting legacy
code. Fortunately, most .NET code will just work out-of-the box, but
this is not so for unmanaged DLLS.

Depending on your application, you may also try to run the main
process in 64 bit and delegate some work to a 32-bit process

Hi,

This is an update for this issue.
I built an test environment(x64), I found two appraoches worked for x64
scenario.
1. Build the .NET application as x86 modal, so it will run as an 32bit app
in WOW64, per the MVP's suggestion in the link below.
VB6 Library import / tlbimp problem on x64
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=706695&SiteID=1

2. Put the vb6 dll into COM+, and enforce it as an Server Application(not
library application). This should be available in ASP.NET scenario because
the x64
2.1 Run dcomcnfg
2.2 Add a new empty COM+ Application and indicate it as Server application
2.3 Add the exsiting component(the vb6 dll) into the com+ application.

If you have any further question, please feel free to let me know.


Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.