I am getting the following error if I try to run the ASP.NET 4.0 website in a 64 bit machine with Enable 32 bit Applications flag set to false. (I have to set that to False, If I set it to true its working fine).
> "Could not load file or assembly 'Common.BL' or one of its dependencies. An attempt was made to load a program with an incorrect format.
And in the project properties the Target of Build is set to Any CPU.
Still I am getting the same error.
Can you guys please help me resolving this error. Anyhelp would be appreciated.
Thanks.
Sameer.
I'd focus on the "or one of its dependencies" portion of the error. Are you referencing a 32-bit assembly or one compiled for a different platform?
Ensure Common.BL is 64 bit. You can check this fairly easily. Check this out for help:
How to determine if a .NET assembly was built for x86 or x64?
Let's use that as a starting point, post the results. If it is a 32 bit and you are on IIS 6, then ALL of IIS must be set to run in 32 bit mode.
If you are in IIS 7 then you can set a specific app pool to run in 32 bit mode. Ensure you compile your code for 32 bit though.
Related
have web setup project created by VS 2010, when i setup this project all works fine, but when i check "repair" option i get error during installation.
MSI log file
Running process 'c:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 32 bit mode, while this application is a 64 bit application and thus not compatible.
Trying 32 bit version of 'aspnet_regiis.exe'...
Reading registry value Path from key 'HKLM\Software\Microsoft\ASP.NET\4.0.30319.0'...
RESULT Path =
Running process 'c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
I couldnt uderstand why both 32-bit and 64-bit versions of aspnet_regiis not compatible to application?
When i check "setup" not "repair" option, path param is set to my application and setup works fine, so maybe i have to change something in my setup project?
IIS6 is set to 64-bit mode by the way ;)
Thanks
If you support 32 and 64-bit systems you need separate setups for both.
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
so you'd run the appropriate aspnet exe for the system, that might solve some problems. You haven't said if your setup is x86 or x64, so it's hard to say what the exact issue might be. 32-bit processes cannot call 64-bit Dlls (and vice versa) so the 32-bit aspnet_regiis.exe can't call 64-bit assemblies in a 64-bit IIS, that's probably something to do with it.
That doesn't look like an MSI log file because it hasn't got all the info in there, like the MSI (s) (74:1C) [12:14:05:000]: type of intro, plust suff that would tell you if the call to the ProgramFiles folder is being redirected (look for WIN64DUALFOLDERS in the log).
I'm having issues with redemption because Outlook 32 bit can be installed on a 64 bit machine. The RedemptionLoader doesn't determined the bit version of Outlook installed on a 64 bit machine. Has anyone run into this before?
The problem is that you can't use 32 bit DLLs in 64 bit processes. But there's a workaround I've found after a long period of search.
It's possible to run the 32 bit Redemption-DLL in a 32 bit DllHost.exe process. Now you're able to access this DllHost.exe*32 by your x64 or AnyCPU application, because THAT is possible.
That sounds complicated but is relatively simple.
First register your Redemption.dll (x86) on the system. I've done it this via:
regsvr32.exe "C:\Program Files (x86)\Redemption\Redemption.dll"
If you start your application without registering the Redemption.dll you'll get an exception like:
COMException: Retrieving the COM class factory for component with CLSID {29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following error: 80040154 Klasse nicht registriert (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Once the 32 bit DLL ist registered you need to add some keys and values to your Registry.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"DllSurrogate"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"AppID"="{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"DllSurrogate"=""
What's now happening when start your application is that the system starts a DllHost process which loads the Redemption.dll in a x86 environment. You will see a dllhost.exe*32 with a COM Surrogate description on task manager, after you've started your x64 application. All accesses to Redemption.dll will now be routed to the DllHost.
Of course you have to add these registry keys only on x64 systems with a x86 Outlook client ;)
Hope this will help some of you :)
RedemptionLoader does not determine Outlook bitness because it won't do you any good: it determines the bitness of the calling process and loads the appropriate version of Redemption (32 vs 64 bit), but that can raise an error if the bitness of your process/Redemption is different from the Outlook bitness. A 32 bit dll cannot be loaded by a 64 bit process.
See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for more details.
It is possible to load a 32 bit DLL in a 64 bit PowerShell session. See my answer here for more details.
In short, you can use Start-Job -RunAs32 which loads a 32 Bit PowerShell version
I've written an ISAPI extension using Visual Studio 2012 on windows 7 that is a very simple passthrough wildcard extension. When compiled as 32 bit, and with the app pool set to allow 32 bit applications the filter works well. But when I compile as 64 bit (and change the pool to NOT allow 32 bit) I get a 500 error with the code 0x8007007f. 64 bit depends shows all green. There are no errors in the event log. I tried moving the DLL to C:\Windows\System32 but am getting the same error. Any help would be greatly appreciated.
Thanks
Marc
The reason might have been that the 64 bit DLL did not export the functions HttpExtensionProc and GetExtensionVersion, which the error name hints at:
Logfile:
Notification
EXECUTE_REQUEST_HANDLER
ErrorCode
The specified procedure could not be found.
(0x8007007f)
I had missed adding the .def file to the linker options in my project.
Windows Web Server 2008 R2 (x64) &
.Net Framework 4.5
It is a classic ASP.Net Web Site (Not a web project, code is in App_Code directory and compiled when the site is being launched)
And it depends on many reference DLLs in /Bin directory.
For those DLLs I have source code, I compile them targeted as "x64" platform.
And I have some other DLLs without source code (mysql.data.dll / etc), which are compiled as "Any CPU".
I modified them in EditBin.exe to ensure the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is indicated in their PE header.
According to this table:
http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx#memory_limits
x64 process can't use more than 2GB memory unless IMAGE_FILE_LARGE_ADDRESS_AWARE is set.
How can I verify whether it works?
Is there any place I can see the memory limitation of running x64 process?
I don't know if you can actually "see the memory limitation" explicitly stated (assuming you don't trust MS's own documentation that you cited) other than getting your hands on and digging into the IIS and/or ASP.NET source code.
That being said, you could try stress testing the site, and monitor memory consumption (via Task Manager or Process Monitor), to see if it exceeds 2GB. I would recommend tinyget, part of the IIS 6 Resource Kit, which can still be used with IIS 7.
tinyget -svr:localhost -uri:/<your site> -loop:200 -threads:20
You'll have to play with the loop and thread count to try to push it over 2GB. I would expect to see an System.OutOfMemoryException as you approach about 1.4GB of combined physical and virtual private bytes. You may want to create a stress test function in the site itself, for testing purposes only of course, which will help you reach this limit, by using the exact opposite of good practices. You can read more about what would lead to an System.OutOfMemoryException` here, and then do things they recommend against. For example, add a test method that just concatenates strings in a very large loop.
try procexp, from sysinternals here. This application can monitor .NET specific metrics.
Nevertheless, according to your link, you should be able to address at least 8GB.
Please keep in mind that enforcing the IMAGE_FILE_LARGE_ADDRESS_AWARE is irrelevant in your case. You could have all your components compiled to target "Any CPU", the only flag that is checked is the flag of the executable file.
I have been trying to work on integrating a NewsLetter for a companies local intranet and I keep running into the same error that everyone seems to be getting. I am running this on IIS 5.1 and on error exists at Server.CreateObject(ADODB.Connection), also the purpose of the ASP code is to read an Excel file
Error Type:
Server object, ASP 0196 (0x80040154)
Only InProc server components should be used. If you want to use LocalServer components, you must set the AspAllowOutOfProcComponents metabase setting. Please consult the help file for important considerations.
I have tried the solution to locate to my AdminScripts directory and setting the boolean value to True with cscript adsutil.vbs set /w3svc/aspallowoutofproccomponents True and then verified by cscript adsutil.vbs enum /w3svc > verified.txt
Opening up the textfile, it does show that the value is set to true but I run into the same error again when trying to access the ASP page. I am at a loss, I figured after reading all those people post questions that I'd ask the question myself.
I cringe at the sight of that error messages, please make my nightmare end.
Its a bizare error to be getting in the first place. Why would the simple ADODB.Connection object be considered an out-of-process component?
The only thing I can think of that might cause this is if someone has accidently dragged the ADO dll into a COM+ Service. Check the set of COM+ Services anything unusual installed there?
In an attempt to repair you could download the latest MDAC from Microsoft's download area and re-install it on your machine.
Enabling out-of-proc components to is not the answer ADODB.Connection should not be out-of-proc.
Next Step
Fire up Regedit, find in Keys the key value of {00000514-0000-0010-8000-00AA006D2EA4} under
HKEY_CLASSES_ROOT
You should find an InprocServer32 key with a default value: C:\Program Files\Common Files\system\ado\msado15.dll
The ProgID should ADODB.Connection.2.8.
I had to use:
Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"
in the command window to have the InProcServer32 key appear, thank you Anthony.
Everything is up and working now. My nightmares are over!