locked
Oracle.DataAccess causes 64 bit / 32 bit error in ASP.NET / Visual Studio 2005

    Question

  • This one is driving me nuts.

     

    I have developed some ASP.NET pages using Web Developer Express on a 64 bit (Intel Xeon Quad core) machine. This has gone very well, part of my code access an Oracle database using the Oracle.DataAccess.Client namespace (Oracle 64 bit ODP.NET version 2.102.3.2). All works beautifully.

     

    Just bought the full version of Visual Studio 2005, and now when I try to build my web site, I get an error saying "Attempted to load a 64-bit assembly on a 32-bit platform...". The site won't build.

     

    This makes no sense to me. ASP.NET is configured to run under the 64 bit .NET 2.0 framework. A call to IntPtr.Size on a page confirms that ASP.NET is running in 64 bit mode. So why should VS 2005 tell me I am trying to load a 64 bit assembly on a 32 bit platform???

     

    I have SP1 for VS2005, by the way...

     

    Incredibly frustrating...

     

    Nick

    Wednesday, June 20, 2007 8:54 AM

Answers

  • Hi Friends,

     

    By consulting with other engineers internally, here is the complete story for the problem.

     

    When we build an ASP.Net Web Site with Visual Studio, the “devenv.exe” will attempts to load all assemblies into its process space. “Devenv.exe” is a x86 32-bit process, as a result, it is not able to load assemblies built with type “x64”. On the other hand, if the assembly is built with “Any CPU” option, both 32-bit and 64-bit processes will be able to load it.

     

    It seems that the Oracle module is specifically built with the x64 option, instead of “Any CPU”, hence Visual Studio is not able to load it.

     

    To workaround this problem, I would suggest the followings:

     

    1. Do we have a version of the Oracle module built with “Any CPU”, instead of “x64”?

     

    2. Use the 64 bit “aspnet_compiler.exe” to built the web site from the command line:

     

       C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_compiler.exe -v /MyApp -p c:\myapp c:\MyTarget

     

    3. Use the “Web Application Project” template brought back by VS 2005 Service Pack 1. Please give it a try and see whether it helps or not.

     

    Thank you all for your active participation!

    Wednesday, June 27, 2007 6:24 AM
  • Thanks for the detailed information Martin - great to get some comprehensive information on problems like these.

     

    In the end, my solution was none of the above. As far as I know, Oracle do not provide the module built with "Any CPU" - clearly they should. The second suggestion, while I'm sure would work, is not terribly attractive from the point of view of manageable development cycles, debugging etc. I haven't tried the third, as I am using the ASP.NET AJAX-Enabled web site template.

     

    What I did was to use Microsoft's System.Data.OracleClient, rather than the Oracle version (Oracle.DataAccess.Client). The end result is the same (for my purposes any way), with the important difference, that System.Data.OracleClient is available in both x86 and x64 builds. In practice, once the web site is built, the x64 build is used (which in turn uses Oracle's drivers), but it keeps the VS compiler happy, as it can "see" an x86 version.

     

    By the way, it is still a complete mystery to me (and hardly acceptable) that this problem affects Visual Studio 2005 (SP1), and not Visual Web Developer Express (SP1). I can't follow any logic that might explain this.

     

    Cheers,

     

    Nick

    Monday, July 16, 2007 12:36 AM

All replies

  • Hi Ntompson,

     

    It seems as though VS does not setup the msi configuration properly and always references the 32-bit framework. 

    If you checked the path for the default references, you will find that they are pointing to the 32 bit version of the .net framework.

    Related case: http://blogs.msdn.com/heaths/archive/2005/10/24/windows-installer-on-64-bit-platforms.aspx


      Solution:

    Install 64-bit registry information, use: %systemroot%\Microsoft.NET\Framework64\v2.0.50727\installutil.exe.

    This is described in http://msdn2.microsoft.com/en-us/library/ms714644.aspx

     

    By the way, we cannot call a 32-bit DLL from a 64-bit application. We will either need to obtain a 64-bit version of that library, or, have the 64-bit application run 32-bit in WOW.

    • Proposed as answer by HariSantosh Tuesday, October 20, 2009 6:18 AM
    Thursday, June 21, 2007 5:28 AM
  • Sounded promising, but no cigar.

     

    Here is what I did: at the command line, executed InstallUtil.exe in the 64 bit framework system directory:

     

    C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe C:\oracle\product\10.2.0\client_1\odp.net\bin\2.x\Oracle.DataAccess.dll

     

    This executed successfully, but I still get the same error when I try to build my solution with a reference to Oracle.DataAccess.dll in a web project. (Having the same reference in a C# project causes no problems.)

     

    Perhaps I am not doing what you think I should?

     

    Thanks,

     

    Nick

    Friday, June 22, 2007 12:08 AM
  • I'm having the exact same issue. When I try to build a simple asp.net project in visual studio 2005 on a 64-bit server it builds fine but as soon as I add a reference to any 64-bit assembly (i.e. Oracle.DataAccess or other 64-bit projects) I get the message "Attempted to load a 64-bit assembly on a 32-bit platform".

    Since I can compile other class projects in 64-bit without a problem, I'm assuming that this issue is related to asp.net/IIS or the asp.net Development Server used by Visual Studio when building asp.net applications. I know my IIS is running in 64-bit mode (I've even set the Enable32Bit... flag to false).

    Is it possible that the asp.net development server in Visual Studio isn't running in 64-bit?
    Friday, June 22, 2007 2:08 PM
  • Hi Ntompson and Jaga,

     

     Please ignore my previous post.

     Try the following command-line tools to compile your project in 64-bit server.

     

    1) Visual Studio 2005 x64 Cross Tools Command Prompt

        Locates at Start Menu -> Visual Studio Tools

        Use "devenv" compile command


      2) .NET 2.0 SDK 64-bit

    Tuesday, June 26, 2007 3:05 AM
  • Hi Martin,

     

    I followed your instructions for starting Visual Studio through the x64 Command Prompt but Im still receiving the same error message when I compile my ASP.NET project. 

     

    I didn't really understand what you meant by step 2. I already have the .NET 2.0 SDK 64-bit installed on my machine.

     

    This one is very frustrating...

    Tuesday, June 26, 2007 2:27 PM
  • I too am having this error.  The error occurs for me when I attempt to create a data source using the Oracle Client for .NET.  Any ideas?

     

    Adam

    Tuesday, June 26, 2007 6:19 PM
  • Hi Friends,

     

    By consulting with other engineers internally, here is the complete story for the problem.

     

    When we build an ASP.Net Web Site with Visual Studio, the “devenv.exe” will attempts to load all assemblies into its process space. “Devenv.exe” is a x86 32-bit process, as a result, it is not able to load assemblies built with type “x64”. On the other hand, if the assembly is built with “Any CPU” option, both 32-bit and 64-bit processes will be able to load it.

     

    It seems that the Oracle module is specifically built with the x64 option, instead of “Any CPU”, hence Visual Studio is not able to load it.

     

    To workaround this problem, I would suggest the followings:

     

    1. Do we have a version of the Oracle module built with “Any CPU”, instead of “x64”?

     

    2. Use the 64 bit “aspnet_compiler.exe” to built the web site from the command line:

     

       C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_compiler.exe -v /MyApp -p c:\myapp c:\MyTarget

     

    3. Use the “Web Application Project” template brought back by VS 2005 Service Pack 1. Please give it a try and see whether it helps or not.

     

    Thank you all for your active participation!

    Wednesday, June 27, 2007 6:24 AM
  • Thanks for the detailed information Martin - great to get some comprehensive information on problems like these.

     

    In the end, my solution was none of the above. As far as I know, Oracle do not provide the module built with "Any CPU" - clearly they should. The second suggestion, while I'm sure would work, is not terribly attractive from the point of view of manageable development cycles, debugging etc. I haven't tried the third, as I am using the ASP.NET AJAX-Enabled web site template.

     

    What I did was to use Microsoft's System.Data.OracleClient, rather than the Oracle version (Oracle.DataAccess.Client). The end result is the same (for my purposes any way), with the important difference, that System.Data.OracleClient is available in both x86 and x64 builds. In practice, once the web site is built, the x64 build is used (which in turn uses Oracle's drivers), but it keeps the VS compiler happy, as it can "see" an x86 version.

     

    By the way, it is still a complete mystery to me (and hardly acceptable) that this problem affects Visual Studio 2005 (SP1), and not Visual Web Developer Express (SP1). I can't follow any logic that might explain this.

     

    Cheers,

     

    Nick

    Monday, July 16, 2007 12:36 AM
  • Hi Martin,

     Thanks for the information provided by you. i have an issue when tried to install windows service which was built targeting  x64.
      By using the second approach. am able to install my services.

    Regards,
    Hari Santosh.
    Tuesday, October 20, 2009 6:20 AM
  • this problem happens becouse you must change your project to run it in a x86 CPU, you can still use the System.Data.OracleClient to connect to Oracle 10 or later. If you have any problem whit the Oracle client in your server, you can download and install the ODP.NET from oracle.com, follow the instructions to setup it and ready .
    It Director
    Thursday, October 07, 2010 10:18 PM
  •  

    i tried this compilation stuff it did not work i get error not valid virtual path

    i tried one time to use physical path and another time to use the virtual path

    C:\Windows\Microsoft.NET\Framework64\v2.0.50727>aspnet_compiler -v c:/inetpub/ww
    wroot/Myrms/WebSiteOdp
    Utility to precompile an ASP.NET application
    Copyright (C) Microsoft Corporation. All rights reserved.

    error ASPRUNTIME: '/c:/inetpub/wwwroot/Myrms/WebSiteOdp' is not a valid virtual
    path.

    C:\Windows\Microsoft.NET\Framework64\v2.0.50727>aspnet_compiler -v c:/inetpub/ww
    wroot/Myrms/OracleWebSite
    Utility to precompile an ASP.NET application
    Copyright (C) Microsoft Corporation. All rights reserved.

    error ASPRUNTIME: '/c:/inetpub/wwwroot/Myrms/OracleWebSite' is not a valid virtu
    al path.


    .net developer
    Wednesday, December 21, 2011 5:32 PM