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.

Asante

Did you find an answer to this question outside of Stack Overflow? – Stalkinghorse

I didn't...and from what I've read there are no plans to make VS 2010 in a native x64 flavor either due to add-on porting issues and not breaking them all even more than the 2008-2010 upgrade would. Currently I run a different PATH variable on 32 bit mode so VS's web server sees a different Instant Client directory. This allows me to have a x64 and x86 instant client side by side and both can work. It's not entirely ideal since I still have to attach to the x64 IIS process to debug any issue that may be x86/x64 compatibility related but it works for normal development much better. – Asante

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.

Lesser

The XSP web solution is the most promising possibility thus far, looking into it more now. The 2nd option doesn't work because the issues that are hard to debug are at startup. If a driver, library, etc isn't 64-bit friendly and blows up at startup, it's hard to tell this since I can neither hook up a debugger nor even get an error screen in most cases. Example: The server wasn't installed correctly, instant client x86 DLLs were deployed and picked up by a x64 path variable or vice-versa. – Asante

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. – Asante

Answer 2

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

Mcclellan

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. – Questionless

Answer 3

Use IIS on your local machine.

Cathay

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

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

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. – Asante

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

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. – Asante

Answer 4

Even you are using 64-bit environment, temporary refer 32-bit dlls in Visual studio (or manual copy it in BIN folder) so that you can debug it. Keep in mind, every time you compile the code it will re-copy the 64-bit assemblies in BIN folder.

Excommunication