问题描述
Visual Studio 是 x86,直到 Visual Studio 2010
在 IIS 中,应用程序池以 64 位运行,按预期使用 Oracle 驱动程序,但是由于 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.
Two ideas:
- Cobble something together with XSP from the Mono project.
- Test in a totally 32bit environment, deploy to a 64bit environment.
这篇关于如何在 x64 中使用 WebDev.WebServer.exe (VS Web Server)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!