4

First of all, I've previously managed to get one of my 64-bit test web apps to run on this machine (back when I was prototyping for this project). I've been working for a few weeks in 32 bit and realized I need to switch the app over to 64-bit and when I did (Set target platform to x64 in the project) and redeployed, it stopped running.

It took me several days to get 64-bit working last time and I'm not sure what I'm missing this time that I did last time.

I am publishing to and debugging under IIS.

I get a BadImageFormatException with the message: "Could not load file or assembly 'GEMS.Web' or one of its dependencies. An attempt was made to load a program with an incorrect format."

This app references both 64-bit and 32-bit assemblies. I have set "Enable 32-bit Applications" to true in the application pool in IIS.

I'm using VS.NET 2012, IIS 7.5, running on a 64-bit Win 7 machine.

The following is from the assembly load trace:

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Windows\SysWOW64\inetsrv\w3wp.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = XXXXXX\xxxxxx
LOG: DisplayName = GEMS.Web
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: GEMS.Web | Domain ID: 2
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///c:/inetpub/wwwroot/GEMS.Web/
LOG: Initial PrivatePath = c:\inetpub\wwwroot\GEMS.Web\bin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\inetpub\wwwroot\GEMS.Web\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/gems.web/eea5792e/72317e39/GEMS.Web.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/gems.web/eea5792e/72317e39/GEMS.Web/GEMS.Web.DLL.
LOG: Attempting download of new URL file:///c:/inetpub/wwwroot/GEMS.Web/bin/GEMS.Web.DLL.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
Pete
  • 6,585
  • 5
  • 43
  • 69

2 Answers2

6

Change your IIS to handle 64 bit processed using the following method: Tools | Options | Projects and Solutions | Web Projects | Use the 64 bit version of IIS Express

BrianLegg
  • 1,658
  • 3
  • 21
  • 36
3

If you are not using any native Win32 libraries, you should target Any CPU for your assemblies and not mess with the Enable 32-bit Applications setting in IIS (leave it to false).

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 2
    I'm not sure what you mean. My app must be 64-bit because I'm referencing 64-bit assemblies. If I set it to Any CPU, then when I hit code that loads those 64-bit assemblies, they fail to load. – Pete Dec 07 '12 at 15:49
  • Do you have control over those assemblies? If, yes then change them to be Any CPU as well. If not, contact the author of those assemblies and ask him to provide you CPU bitness agnostic versions of them (Any CPU). – Darin Dimitrov Dec 07 '12 at 15:50
  • No, I don't have control over the Crystal Reports assemblies. I must use the 64-bit Crystal because if I use the 32-bit version of Crystal, I run into this issue: http://stackoverflow.com/questions/4208516/crystal-reports-error-when-deployed-could-not-load-file-or-assembly-log4net Now, there is away around that by using a specfic verison of the 32-bit log4net.dll available from SAP, however that then conflicts with the log4net references in Castle. Having fought this battle before, getting the 64-bit stuff working last time was the easier solution. – Pete Dec 07 '12 at 16:11