Problems Deploying Web Application

Question

User1662546157 posted

Hi there!

I've recently created an ASP.NET web application (using Visual Studio 2005) that uses a COM DLL to do some vital processing.
I have been trying to deploy this project onto a server that is running Windows Server 2003 64bit.
When I try to run the web application on this new server I get the following error when the application tries to use the COM DLL:

Exception: Retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154. 

The COM DLL has been developed using VB6 and is meant to be run on a 32bit operating system.
It was only after using the Depends.exe that comes with Visual Studio 2005 that I realized that there are CPU conflicts concerning this DLL.
I've tried registering the DLL on the server but the web-application ignores the registered DLL and uses the one in the project's "bin" folder.

I'm wondering anyone could share with me how to compile my web-application in Visual Studio 2005 so to target the 64bit platform.
I'm not even sure if this will solve my problem.

Any ideas on how to fix this issue are welcome.
Thanks alot

-Frinny 

Answer 1

User1347944086 posted

Your component is not registered on your server.

Check it first. It must be functionnal before you can use it from your Web App.

That's not a Web Deployment Project problem.

Answer 2

User1662546157 posted

Thanks for your advice Steff,

I had installed registered the DLL.
I used the DLL in a Windows Application to test to make sure that it worked, and it worked perfectly.
The DLL was only causing the error when the Web Application tried to use it.

I think the problem might have been that the Interop in the web project was trying to point to a DLL registered in the system32 folder, but because I was trying to run the DLL on a 64bit Operating System the DLL was actually registered in the SysWoW64.

 

I'm not sure how the Interop works and I'm not sure how it refers to the DLLs or how the registry works on a 64bit OS.
I had the IIS set up to run 32bit applications so I don't know why this wasn't working.

Try as I did I never solved this problem and I don't think that I will ever understand why it wouldn't work.

I have formatted the server and installed a 32bit Operating System because I could not solve this problem.
The Web Application works fine on the other two 32bit development servers and I am not expecting to find any more crazy errors.

Thanks again for your help

-Frinny
 

Answer 3

User1347944086 posted

Strange...

I have a Web Application running on Server 2003 x64 using Log Parser (COM interface) with no problem.

There is only one binary, one path, the same with a x86 or x64 client.

The interop try to instantiate your component using its classid.

Perhaps your component is badly registered.

You said it was working with a "Windows Application". Do you mean a .NET Windows Application ? Your application may instantiate the COM component with it's ProgID, not it's ClassID.

You can check also the registry and look to progid and classid entries....

That's juste an idea...

 

Answer 4

User1662546157 posted

Hi Steff,

It may well have been that the component was registered badly...but I don't remember seeing an error in when running regsrv32.
The Windows Application I used to test the DLL wasn't a .NET application.  It could have been using the ProgID instead of the ClassID.

I've only just touched on GUID's and have no idea what the difference between a ProgID and ClassID is.

The web-application is working perfectly on the 32-bit operating system now.
I hate taking such extremes to solve problems and would have loved to gotten to the bottom of why it wasn't working on the 64-bit OS, but I have to meet a deadline that is quickly approaching.

 

Thanks for your help!

-Frinny 

Answer 5

User1347944086 posted

It was only after using the Depends.exe that comes with Visual Studio 2005 that I realized that there are CPU conflicts concerning this DLL.

What's the problem ?

I've tried registering the DLL on the server but the web-application ignores the registered DLL and uses the one in the project's "bin" folder.

You should only have the interop in bin folder. Anyhow if you regsvr32 another physical dll this one should be used, not any other ones.

but I don't remember seeing an error in when running regsrv32

regsvr32 won't tell you that registry entries are bad.

I've only just touched on GUID's and have no idea what the difference between a ProgID and ClassID is.

ProgID is the human readable form, IndependentVersionProgID is the versionless ProgID and ClassID is the GUID form.

For example :

ADODB.Command.2.80 is the ProgID for the object Command version 2.8

ADODB.Command is its IndependentVersionProgID

and {00000507-0000-0010-8000-00AA006D2EA4} its ClassID.

The object can be instantiate using one of the three. If the IndependentVersionProgID is used it shall instantiate the latest registered version.

 

 

 

It looks like one entry is missing in the registry. One of your component but as you are using VB6, it may come from one of VB runtime.

I'll try to uninstall and reinstall the component but also all VB runtime. I'll try to deploy on another x64 machine but you may not have one more...

There may be a confusion/setup problem between "Program Files" and "Program Files (x86)".

I've juste grab the ADODB.Command entries to show how it should looks like for your component. But it's painful to check VB runtime... I'm afraid I cannot help you any longer...

...But logically if it works using a ProgID it should work using a CLSID

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ADODB.Command]
@="ADODB.Command"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ADODB.Command\CLSID]
@="{00000507-0000-0010-8000-00AA006D2EA4}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ADODB.Command\CurVer]
@="ADODB.Command.2.8"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ADODB.Command.2.80]
@="ADODB.Command"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ADODB.Command.2.80\CLSID]
@="{00000507-0000-0010-8000-00AA006D2EA4}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}]
@="ADODB.Command"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\InprocServer32]
@="C:\\Program Files\\Common Files\\System\\ado\\msado15.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\ProgID]
@="ADODB.Command.2.8"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\VersionIndependentProgID]
@="ADODB.Command"

Answer 6

User1662546157 posted

Hi Steff,

 

Thanks for all your help.  It is very much appreciated. 

I am no longer experiencing any problems with my web-application ever since I re-installed the server to be a 32-bit version Server 2003.
Since I destroyed the state of the server I cannot call up the errors that were happening on the 64-version of Server 2003.

 
Thank you for clearifying the difference between a ProjID and CLSID.

[:)] 

-Frinny