May you help me, My ASP.NET application can't import excel file when migrating this application that run in Win Server 2003 32-bit to the Win server 2008 64-bit environment.
How to fix this bug? because in Win Server 2003 32-bit, it runs properly.
the error report that appear is:
*System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad) at Admin_ImportRisk.CreateTempTable() in C:\inetpub\wwwroot\ERMApproval\Administrator\ImportRisk.aspx.vb:line 66.*
The code in line 66 of my application is:
oBooks.Open(Server.MapPath("~/App_Data/Risk.xls"))
I have tried several scenarios:
Added Network Service user to the Microsoft Excel Application in DCOM configuration and set the identity of Application pool that in used to be same.
Added all many kind of user to the Microsoft Excel Application and My computer in security of DCOM configuration. And I have added many kind of user too in the application's folder.
Used corflags.exe to force 32-bit application to run in 64-bit environment
Used regsvr32.exe to register a Microsoft.Office.Interop.Excel.dll file to the windows 32-bit component services.
Used rundll32.exe to run the 32-bit Microsoft.Office.Interop.Excel.dll file in the 32-bit environment
But the result is still the same.
It will be a big honour if you can help me^^.
Best regards,
-imanuel-
The simple answer is to compile your project to target x86 only. This is a setting in the project settings. So the .net framework will only generate a 32 bit application at runtime, rather than defaulting to 64 bit. This is no different from setting corflags, however if you have multiple assemblies you ahve to make sure it's done for all of them. The application itself must target only 32 bit.
You're using a COM component that is 32 bit, and you can't do that in a 64 bit application, so force it to be 32 bit.
You can also force IIS to run it in the 32 bit context as documented here:
http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Also, make sure the 64 bit version of Excel is not installed on the server, but rather the 32 bit version.
Related
Can anybody tell how to debug the Com Dll in IIS 7.0 using VB 6.0 in Windows Server 2008 R2.
I am able to hit break point in VB 6.0 accessed from Console Application using interop dlll.Through ASPX pages in IIS 7.0 I am getting the following Exception
Unable to cast COM object of type 'XCreateUser.XAcctUserProfileClass'
to interface type 'XCreateUser._XAcctUserProfile'. This operation
failed because the QueryInterface call on the COM component for the
interface with IID '{7A48FABA-CCC8-4FA6-94E8-803F6CF121F2}' failed due
to the following error: Error loading type library/DLL. (Exception
from HRESULT: 0x80029C4A
Already DLL built and registered and com interop dll generated.
Please somebody show some light on this
Already DLL built and registered
"Registered" is the problem here, it wasn't correctly registered. This is an exception message that's generated by the CLR when it tries to locate the proxy for a .NET component that is [ComVisible]. A proxy is required to make a call to a COM component from a worker thread that doesn't do anything to help make the call thread-safe. A thread that's in the MTA, usually a thread-pool thread.
A .NET component is registered with Regasm.exe. You forgot to use the /tlb argument.
Should be simple to fix. If you still have trouble then SysInternals' Process Monitor is the weapon of choice.
I generally debug these things as you say through a console or windows forms application. You can always add logging to your web app to see what parameters are being passed to it.
Generally errors like the above are setup issues when running on a 64 bit platform and when utilizing 32 bit dlls. One thing to make sure of is that your application pool allows 32 bit applications. In IIS Manager right click on the application pool your website is running under and go to Advanced Settings->Enable 32 bit Applications. Set that to True.
You'll also need to make sure that your 32 bit dll is registered in the 32 bit registry hive. C:\Windows\syswow64\regsvr32 is the version you'll need to use to register this dll.
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 tried installing my old ASPImage from server Objects in my new server, but the object is not created even though the dll is registered and ASP is enabled in IIS7. Does anyone have any ideas on this issue, or used a different component that can be called from VBS as well as ASP classic?
I tried running tests on the object and it returns internal server errors. When running in VBS, no errors but it ignores the object.
Thanks
James F.
Assuming you have a 64 bit Web Server, you have to enable the setting "Enable 32-Bit Applications" in the Application Pool using the 32bit Component.
See here for further details:
http://help.webcontrolcenter.com/KB/a1114/how-to-enable-32-bit-application-pool-iis-7-dedicatedvps.aspx
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.
I'm wondering if anyone else has experienced failed DLL's after upgrading their servers.
My company is in the process of upgrading our code and server's after ten years of using classic ASP. We've set up our new server running Windows 2008 and IIS 7. Our classic ASP code and our new asp.net mvc code work pretty well.
Our problems started happening when we began moving our old websites to the new server. When trying to load the page on the actual server machine's browser, we initially got a 500 error. If we refreshed the page then some of the page would load but then display an error:
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/folder/scriptname.asp, line 24
800401f3
btw: On remote machines we would just get 500 errors.
Line 24 is the first executable code in the script:
'23 lines of comments
set A0SQL_DATA = server.createobject("olddllname.Data")
'the rest of the script
That specific line is trying to use a ten year old DLL to create a server object. I don't think the server configuration is a problem because I'm able to create "adodb.recordset" server objects without any problems.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Is there a way to get old DLL's working on 64 bit systems?
Edit
I have confirmed that the site's application pool is running in 32bit compatability mode, but the site still sends the same errors whenever set A0SQL_DATA = server.createobject("olddllname.Data") is called.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Yes, the most prominent example of a 32-bit DLL no longer working on 64-bit Windows seems to be the Microsoft Jet Engine, i.e., the driver required to access .mdb files. Since there is no 64-bit version, the only way to access .mdb files in classic ASP application is to run IIS (or the Application Pool, to be precise) in 32-bit compatibility mode.
How to detect if you are in 32 or 64 bit mode (untested):
Set shell = CreateObject("WScript.Shell")
Response.Write shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
This should output AMD64 in 64-bit mode and x86 in 32-bit mode (either native 32-bit or 32-bit emulation on a 64-bit processor).
Well, error 800401f3 means "invalid class name." That strongly suggests that the DLL is registered with the wrong ProgId (or that the ProgId is missing entirely). When your sys admin verified that the DLL was registered, did he also verify that its ProgId is "olddllname.Data"?