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.
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 curious problem.
A 64-bit Windows 7 Pro box has IIS 7.5/64 installed. An application pool has been configured to enable 32-bit applications, and a site has been created using this application pool. However, when the worker process for the site starts, it is always started as a 64-bit process. The "bitness" of the app pool is evidenced in Task Manager, which has no "*32" tag with the w3wp.exe process name.
I've tried deleting and recreating the application pool, creating a new application pool, and re-registering the 32-bit framework, restarting IIS each time, all to no avail. I'm sure I'm overlooking something trivial, in "forest for the trees" mode, so a push in the right direction to clear up the fog would be appreciated.
I've read through several posts on issues like this, but most center on ensuring the app pool is configured to "Enable 32-bit apps," which was one of the first steps taken.
Have you set
enable32BitAppOnWin64
to true?
This is exposed as a property on the ApplicationPool class that can be set programmatically: ApplicationPool.Enable32BitAppOnWin64.
Also, here is a SO question about setting the property on IIS 7 (not sure if you are on Azure or not, but I believe the idea shold be transferrable to a non-Azure environment).
How to change property Enable32BitAppOnWin64 of Application Pool on IIS 7 on Windows Azure?
Finally, you could set it up in your Application Pool Defaults: http://www.iis.net/configreference/system.applicationhost/applicationpools/applicationpooldefaults
Well, after a couple of days of head scratching, I finally solved this problem.
After verifying through the IIS management tool that each application pool on the box had "Enable 32-bit Applications" explicitly set to True, I went into the machine's applicationHost.config, and those same pools had this property set to False. I manually edited these entries to True, restarted IIS, then re-registered the 32-bit version of ASP.NET, and the machine now operates properly.
Thanks for the suggestions. I'm not entirely why the IIS admin tool was essentially lying to me about the Enable 32 bit app setting, but oh, well... :)
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.
We currently have an web application running on IIS6 on a 32bit machine.
This application is running smooth and stable. It is built with the target "Any CPU".
Now we are copying this exact application to an 64bit IIS7 machine. We only changed the web.config, according to the IIS7 format.
On the application pool we have set the "enable 32bit applications" to true.
When we put some load on this new server, the application behaves entirely different from it's old environment.
We see high CPU and high memory usage. And the memory (private bytes) goes up, but does not seem to be reclaimed when the load ends.
This is not what we expected.
Did anyone encounter this same behavior?
We expect it to be some mistake in the server or application configuration. Any suggestions what settings to check?
IIS 7 introduces the new pipe line mode "integrated" for application pools. Running your application in this mode can change the applications behaviour. If you use this mode, change it to "classic" and try again.
I have an ASP.NET application that consumes a lot of memory. Therefore I want to use the Debug Diagnostic Tool to try to search if there might be a leak or something else.
In DebugDiag on the process tab I right click the w3wp.exe process and the only options I get are:
Terminate process
Copy
Only on some processes I get more options:
Monitor for leaks
Create full userdump
Why is this? Has it something to do with the identity of the worker process?
Can someone help me solve this so I can debug the worker process I am interested in?
Assuming you are are using DebugDiag 1.1. You need to use the correct version that matches the process architecture (there are 32bit and 64bit versions).
To check whether your application pool's worker process is 32bit or 64bit go to:
Control Panel -> Administrative Tools -> Internet Information Services (IIS) Manager
Don't open Internet Information Services (IIS) 6.0 Manager.
Open the Advanced Settings for your website (the link is on the Actions pane to the left). Note the Application Pool name then click Cancel.
Click on the Application Pools node on the left hand navigation tree pane and right click on the Application Pool noted above, select Advanced Settings.
If the application pool is 32bit then the setting Enable 32-bit Applications will be set to true, otherwise if false the pool will run in 64bit mode.
If the application pool is running in 64bit mode then you need to download and install the 64bit version of DebugDiag.
When you run 32 bit DebugDiag the column "32-Bit" on the processes tab will have "Yes" to indicate that a process is 32bit. Only these processes will have context menu options to 'Monitor For Leaks' and so on.
For more information see Tess Ferrandez's blog:
Capturing memory dumps for 32-bit processes on an x64 machine
If you can reproduce your suspected memory leak in 32bit mode then just switch the application pool to 32 bit and use the 32bit version of DebugDiag. Unfortunately both the 32bit and 64bit versions can't co-reside on the same machine.
Update:
DebugDiag 1.1 x64 only supports the
analysis features. There is a new
version in beta that does permit all
the functionality of the 32bit
version. Although not available
directly you can request a copy from
their support team, see the following
link for more info:
Debug Diag 1.2 (Beta)