I have a web service which loads a 32-bit COM component. I am running this web service with IIS server in my local machine.
When I load the the test page from Visual Studio it succeeds, on the other hand, while loading it using IIS, it display following error
Retrieving the COM class factory for component XXX failed due to the following error: 80070005.
I tried changing the webservice's platform to x86 from Any CPU but that dint help. I am running this on Windows Server 2008 R2 - 64 bit.
I had to enable the 32-bit Applications from the Application Pools settings.
Check permissions on that COM. It may be that when you're running tests from VS, you're running as you (admin), while the user running the website's app-pool is totally different. That user needs to be added read+execute (or, activate, whatever) permissions for "local".
Maybe also see this: Retrieving the COM class factory for component error while generating word document
Sarat, this cannot be right. The "Enable 32-bit Applications" under Application Pools Defaults is not for running 32-bit applications or to solve your problem. It is there to enforce running 32-bit applications UNDER 32-bit processes only, which is not necessary in this case. Most 32-bit applications run fine on 64-bit processes. That's why you can run MS Office 2010 (which is still a 32-bit application) on Windows 7 64-bit machines.
You must have other settings tried and true after nearly a full year answering the original problem.
Related
We have a web application built with target framework as x86.
On Server 2008 (IIS 7/7.5) we are able to run the application without any issue (For 64 bit system we enable 32 bit application from app pool).
On 32 bit server 2003 - no issue.
On 64 bit server 2003 (SP2) - we are unable to load a dll:
Could not load file or assembly 'acPDFCreatorLib.Net' or one of its dependencies. An attempt was made to load a program with an incorrect format.
We know this error comes on 64 bit system when Enable 32bit application is set to false. So I tried the following:
Ran the script:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
The issue persisted.
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ir
On running this the World Wide Web Publishing service stops.
On trying to restart we are getting the following error
ISAPI Filter 'C:\WINDOWS\microsoft.net\Framework\v2.0.50727\aspnet_filter.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture.
Any ideas?
Below worked for me regarding the issue "Could not load file or assembly 'acPDFCreatorLib.Net' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Go to Application Pools => Select the AppPool you have created (Else Choose DefaultAppPool or ASP .Net v4.0)
Right click AppPool and Select Advanced Settings
Set Enable 32-bit Applications to True
Reset IIS and Check
The following fixed the issue for me:-
Right Click "Web Sites" and select property
Go to Services tab.
Uncheck - "Run WWW services in IIS 5.0 isolation mode".
After removing the selection from Run WWW Services...., I was able to start the service.
I have a classic ASP application which I've moved from a Windows 2003 server running IIS6.0 to 64-bit Windows 2008 R2 running IIS7. In IIS7 I've created a website and added an application to that and have set the application pool to enable 32-bit applications.
The application connects to an Oracle database using the ORAOLEDB driver - I've installed the 64-bit Oracle client 11.2.0.3 to connect to the backend Oracle 11g database and can connect fine via the same user as the application using SQLPlus.
When I run the application though, its attempt to connect to Oracle fails with the IIS logs showing the error:
"Provider cannot be found. It may not be properly installed"
I've tried various possible things to try and get this working:
registering OraOLEDB11.dll manually
disabling 32-bit applications from the app pool
using the 32-bit drivers instead both with 32-bits apps enabled and disabled
reinstalling the drivers completely and trying all the above
So far without any luck. The asp code connects as follows:
objOracleConnection.CursorLocation = adUseClient
objOracleConnection.ConnectionString = "Provider=OraOLEDB.Oracle;Data Source=MYDATASOURCE;User ID=USER;Password=PASSWORD;PLSQLRSet=1;OLE DB Services=-2;"
objOracleConnection.Open
EDIT: I've tried a simple VBS script (using essentially the same code as above) to connect and it gets the same error, so IIS may not be the problem. The exact same script works on the Windows 2003 box however.
I've reinstalled the Oracle client via the 'Troubleshoot Compatibility' option, indicating that the application works under Windows 2003 SP1 but still get the same issue from both the VBS script and the IIS application :(
This is an educated guess, but enabling 32 bit applications in IIS7 seems to disable 64 bit applications. If it's a 64 bit driver you may need to disable 32 bit in your app pool
I have referenced some 32 bit and some 64 bit DLL in my ASP.NET MVC 3 project.
The projects compile but I get runtime errors.
It's because I am running the web project as 64 bit.
How do I "enable 32 bit" in my local IIS (just how I can do it in IIS 7.5 Pro)?
I am using .NET 4.0
The error I get is:
Retrieving the COM class factory for component with CLSID {A6775dfd2-1dfF-421C-A187-4D55F4DDFBFF} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
If you don't require the 64 bit component (not sure what is running there or if this can be excluded as you simply wanted to know how to run in 32 bit more)
http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/
You can set it at the server level via:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true
Or set your particular app pool (more recommended imho) you can try the following. Sorry the page this came from is no longer seemingly active and only googles caches is showing it now:
Force IIS to create a 32-bit app pool worker process
If your application is running as a web app, meaning it is running in
an IIS app pool worker process, you’ll want that worker process
(w3wp.exe) to be a 32-bit process. That can be specified in the
advanced settings of the app pool:
Select the app pool for your web app. Click Advanced Settings… under
Edit Application Pool on the right. Change the value of Enable 32-Bit
Applications under (General) to True.
Note that the word “Enable” in the setting doesn’t mean “allow” as in
“allow either 32- or 64-bit applications.” It actually means “force”
as in “force the worker process to run in 32-bit mode so that 32-bit
applications are supported.” This means that the app pool worker
process will always be launched as a 32-bit process when this setting
has a value of True. Setting it to False will launch a 64-bit app
pool worker process.
Note that when an app pool worker process is started, it shows up in
the Image Name column on the Processes tab in Task Manager as
w3wp.exe. When the Enable 32-Bit Applications setting has a value of
True, it will be listed as w3wp.exe *32.
IIS Express 7.5 (as used by Visual Studio 2010 if you install it) is 32 bit only:
http://learn.iis.net/page.aspx/1265/iis-75-express-readme/
To quote:
Both 32-bit and 64-bit systems are supported, however only a 32-bit build of IIS 7.5 Express exists.
So I can't imagine that your problems would be related to the usual 32bit / 64bit pool mode issues that can arise if all of your DLL's are 32bit.
However if you're trying to load a 64 bit COM DLL then this will fail; 64 binaries can't be loaded into a 32 bit process and vice versa.
Another gotcha is forgetting to tick the Use IIS Express checkbox when choosing which web server to debug with:
If you don't tick that checkbox then you'll run your site in a child application in the DefaultWebSite on the version of IIS7 that ships with Windows.
The DefaultWebSite runs in the DefaultAppPool, which in 64 bit versions of Windows runs as a 64 bit process. So you need to change the DefaultAppPool to run as 32 bit if you want to use this instead and consume 32 bit binaries.
You need to do this using IIS7's MMC snap-in or by running the appcmd.exe tool from the command line.
Set your compile target to x86 instead of AnyCPU or x64. Your dll will always run in 32-bit without you needing to mess with the IIS server settings.
I've got stuck with strange Oracle connection error on Windows Server 2003 x64 (IIS 6)
While console .Net application that runs onbehalf of administrator successfully connects to Oracle 10g Express via OleDb [Connection string looks like: Provider=MSDAORA;Data Source=server-ip:port;User Id=user;Password=password;]
ASP.NET 4.0 web-site (application pool runs on behalf of administrator too) fails with error:
The 'MSDAORA' provider is not registered on the local machine
Connection string is the same, but it doesn't work for asp.net site. What shall I check?
Thank you in advance!
This Social.MSDN link seems to point to the fact that you have x86 drivers installed;
From my viewpoint you have two options:
Convert the app to run on 32bit mode in IIS - Can help if you require assistance. LINK
Download and try the 64bit version of the drivers. Oracle x64 downloads
Another approach would be to enable 32-bit applications for the IIS Application Pool your application is using. I would suggest creating a new application pool specifically for your application making sure to enable 32-bit applications.
You'll likely suffer performance issues but at least you'll be up and running.
I have resolved this issue in one of my applications with ASP(MSDAORA connection) - oracle environment with following fix from
http://technet.microsoft.com/en-us/library/cc784046.aspx
following are the steps
To enable IIS 6.0 to run 32-bit applications on 64-bit Windows
1.Open a command prompt and navigate to the %systemdrive%\Inetpub\AdminScripts directory.
2.Type the following command:
cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true
3.Press ENTER.
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.