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.

Answer 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.