How to utilize WebDev.WebServer.exe (VS Web Server) in x64?

Question

Visual Studio is x86 until at least the 2010 release comes around update: this is still an issue in VS2010, there is no native 64bit Cassini support. My question is can anyone think of a way or know of an independent ASP.NET debug server that's x64 for 2008 or 2010?

Background: Our ASP.NET application runs against Oracle as the DB. Since we're on 64-bit servers for memory concerns later, we need to use Oracle's 64-bit drivers (Instant Client).

Setup:

• x64 OS (XP or Windows 7)
• IIS (6 or 7, both x64 App Pools)
• Oracle 64-bit Instant Client (Separate Directory, in the PATH)
• Visual Studio 2008 SP1 Visual Studio 2010

In IIS the application pool runs as 64-bit, uses the Oracle drivers as intended, however since WebDev.WebServer.exe is 32-bit you'll get a BadImageFormatException because it's trying to load 64-bit driver DLLs in a 32-bit environment. All of our developers would like to be able to use the quick debug server via Visual Studio 2008, but since it runs as 32-bit we're unable to. Some problems we run into are during application startup, so although we're attaching to the IIS process sometimes that isn't enough to track an issue down.

Are there any alternatives, or work-arounds? We would like to match our Dev/Val/Prod tiers as much as possible, so everything running in x64 would be ideal.

---

Update for VS 2010

A lot of changes to this question since it was first posted, first VS2010 is out now, it still has the same issues here, however the project I'm on does not. We went through 2 changes to solve this, so I'll post these in hope it saves someone else grief:

The first solution was to load Oracle x86 in 32-bit more, x64 in 64-bit mode, we did this by replacing the assembly reference when running under 64-bit via the web.config, like this:

<configuration>
  <runtime>
    <assemblyBinding>
      <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" processorArchitecture="amd64" />
          <bindingRedirect oldVersion="2.0.0.0-10.9.9.9" newVersion="2.102.3.2" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

The key here is the processorArchitecture="amd64", this means the replacement only happens when running under 64-bit.

Note these versions may be out of date now (if you're reading this caring about Oracle specifically), this was a while back. In addition to the config, we loaded the 32-bit and 64-bit versions of Oracle.DataAccess into the GAC. The 32-bit versions are 10.xxx for Oracle 10g, the 64-bit versions are 2.1xxx, so just swapping the binding using <assemblyBinding> works.

The second, more long-term solution was moving off the Oracle client completely, we're now using dotConnect for Oracle for our Linq-to-SQL provider, and since it's completely managed code using a direct TCP connection, we have no more 32/64-bit specific code in the application, which is much easier to maintain.

I hope whoever finds this also finds the follow-up useful as well. If you have questions about either solution I ended up using, please comment and I'll try and explain in more detail.

Solution 1

Two ideas:

1. Cobble something together with XSP from the Mono project.
2. Test in a totally 32bit environment, deploy to a 64bit environment.

Solution 2

You could try to compile a 64-bit Cassini from source.

Comments

[Nick Craver]

Being unable to debug application startup in 64bit mode was the entire reason the question was posted...

[Amber McCoic]

Maybe I'm misinterpreting it but what stops you from using IIS instead of WebDev.WebServer.exe?

[Nick Craver]

If the app starts up and crashes before the VS debugger can hook onto it (which was/is the case for one bug we had with x86/x64 dlls) it doesn't help us figure out the problem. For normal development I do use IIS, it's just that any startup issues are a real pain to debug.

[Amber McCoic]

You can't put a breakpoint on the first line of code that gets executed when debugging on IIS?

[Nick Craver]

That's the thing, it's often a DLL load issue in the framework before a line of code you can rig a debugger to ever gets hit...those are the issues most likely to arise in a mixed x86/x64 environment...and the hardest to debug when using IIS as the application host.

[Nick Craver]

Mono is working out great given our current linq model, especially for testing. When we get the build 100% worked out for all our needs I'll follow up in case others have the same dilemma. Thanks for the XSP tip, not exactly how we ended up going but a great starting point.

[Admin]

This is how I've done it. (I think someone's efforts were called cassinidev) and it works great! Better for debugging than running 64-bit IIS imo.