Is there any way to make my .NET application use either 32 bit or 64 bit reference, depending on whichever one is available on the running environment?
I've a MSIL built application that currently references the 32-bit version of Oracle.DataAccess, because that's the version installed on my machine. Problem is, some machines only have 64-bit Oracle.DataAccess installed. Is there a way to set my application so that it dynamically references the available dll, regardless of its word size?
Have you tried using the Managed Oracle Data Provider (ODP) for .NET driver? I use it for all my .NET (3.x and 4.x) applications that communicate with an Oracle database. It and the Oracle Instance Client are simple to install and use via XCOPY or NUGET.
Related
Dear Experts : I have an existing MS Access database , and I have created a web API using Visual Studio 2019. I am trying to create an ADO.net entity data model or even Code first . The problem is that I cannot find in the data source when I create new data source , the oledb .
Any idea how to connect to Access via API
Thanks in-advance
Do you have the Access database engine installed?
I would install the Access database engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Make sure you choose the correct bit size. If you running the web server as x32 bits (the default), then install Access x32 (x86) version. If you are running your .net application as x64 bits, then install the x64 bit version of Access. Keep in mind that Visual Studio is a x32 bit application. So, if you choose "any" CPU, it will launch your application as x32 bits.
If you force your project to x64, then you need to have installed the x64 bit version of the Access database engine. Keep in mind that running as x64 bits will work for debug, and running and testing. However, while you can use the connection builders in VS, the final test connection will ALWAYS fail if you using the x64 bit version of Access. This is because VS is a x32 bit application. So, the test connection button will not work, and if you going to use the dataset designer (or now the newer version (entity frame work), then you best develop with the x32 bit version of Access.
If you just developing local, then not a problem, but most hosted web sites (in fact near all) are x64 bits). If you not using the IIS express local, then you have to force your project to x64 bits. And testing connections to the database will be a challenge (your code, or debug code will work, but actual test connections from VS will fail if your project is forced as x64 bits.
I've recently set up a Windows 8.1 64 Bit Machine with Visual Studio 2013 (probably 32 bit, at least it installed itself at Program Files (x86)).
I've also installed the Oracle 11.2.0.1 64 Bit Client with Oracle Data Provider for .NET.
When I do gacutil /l | findstr Oracle.DataAccess, I get four entries, including the following:
Oracle.DataAccess, Version=2.112.1.0, ..., processorArchitecture=AMD64
However, I cannot find Oracle.DataAccess in any of the lists when trying to add an assembly (Oracle.Web is present under Assemblies->Extensions, though).
Do I have to install the 32 bit Oracle Client (or simply 32 bit ODP.NET) as Visual Studio is 32 bit? If so, will the software be able to run on a 64 bit system with a 64 bit application and 64 bit Oracle Client (with 64 bit ODP.NET)?
Yes, Visual Studio is an 32bit application.
It depends on your compilation target (x86 or x64 or AnyCPU) which Oracle Client you need for running/debugging your application, regardless of the architecture from Visual Studio.
AnyCPU will run as 64 bit on a 64 bit Windows (which is most likely the case)
Oracle.DataAccess does not appear because it is an 64bit assembly but your Visual Studio is 32bit.
There are several solutions:
In Add References use the Browse section and locate Oracle.DataAccess.dll manually. Typically you will find it in folder %ORACLE_HOME%\odp.net\bin\2.x\ or %ORACLE_HOME%\odp.net\bin\4\
Open your *.csproj, resp. *.vbproj file with a text editor and add reference manually, i.e. add lines like this under element <ItemGroup>:
<Reference Include="Oracle.DataAccess">
<SpecificVersion>False</SpecificVersion>
<Private>False</Private>
</Reference>
Note: attributes like Version=... or processorArchitecture=... are not required. Your application will load the correct Oracle.DataAccess.dll depending on selected architecture and target .NET framework (provided that it is installed properly - also on your target machine)
Install both x86 and x64 Oracle Client on your machine. Here is an instruction how to do this: Stack Overflow - Install Oracle x86 and x64
Use the ODP.NET Managed Driver from Oracle. You can download it from here: 64-bit Oracle Data Access Components (ODAC) Downloads This works also with 32bit applications.
Open your Registry editor and check if RegKey HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\ODP.NET resp. HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\ODP.NET exist. Both RegKeys contain only the (Default) value with location of your Oracle.DataAccess.dll.
Example:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\ODP.Net]
#="c:\\oracle\\product\\11.2\\Client_x86\\odp.net\\bin\\2.x"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\ODP.Net]
#="c:\\oracle\\product\\11.2\\Client_x86\\odp.net\\bin\\4"
Check your target Framework in compile options. When you have ODP.NET version 4.x installed you must select target .NET Framework 4 or higher in order to see the ODP.NET entry in reference list.
I'm using the Oracle Data Access(ODP.NET) in a mvc3 project.
the odp.net has both x64 and x86 versions separately and i want to use the x64 version.
I set "Platform target" to x64 and add a reference to x64 version of odp.net, there is no problem to publish on iis server, but i can't run the project for develop and test, however Razor views display errors on c# statements.
How i can develop the project in x64 platform?
I would say the immediate problem is forcing your platform target to x64. The asp.net development server is 32 bit. Either leave it as "Any CPU" or run a 64 bit dev server (either the local IIS server or compile cassinidev as 64 bit). If you do leave it as any cpu so you can continue to use the out of the box dev server, you'll get the same error with the 64 bit version of oracle.dataaccess.dll for the exact same reason.
I install the 32 bit version on my machine (i also install the 64 bit version but I mention that only to note that they run fine side by side). The reference to Oracle.DataAccess.dll does not include bit-ness, only version. So as long as you have the same version (or later with publisher policies) of the 64 bit flavor on the server, everything will run fine once you deploy.
I installed the odp.net 32 bit installation for Visual Studio 2012. I set a reference to the Oracle.DataAccess.dll and my connection to Oracle seems to be working.
When I build the project (.net 4) I get the following error. The project is set to build AnyCPU (my workstation is 64 bit and the server where we will ultimately deploy to is 32bit)
'There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference Oracle.DataAcess, Version 4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86, "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architecture between your project and the references, or take a dependency on reference with a processor architecture that matches the targeted processor architecture of your project'
This is only a vs.net warning however is there any way to get rid of this?
Like you said, it's just a warning. Because ODP.net is not "AnyCPU" the warning indicates that you have a dependency that is not going to adapt to the host operating system as your own application is. As long as your odp.net install matches the os in terms of bits, you'll be fine. But the compiler is unable to make that determination and is trying to give you a heads up.
I did find a connect article on this which includes a possible change (i'm assuming to the proj file) to disable the error:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
In any case, your "AnyCPU" application will run fine on your server as long as the 32 bit odp.net you install on the server is the same version as the 64 bit odp.net you referenced (or publisher policies are properly installed to redirect to a later version). To eliminate any confusion i generally set "Copy Local" for the reference to "false." In otherwords, I compile against a specific version of the dll but let it run against what it resolves from the GAC (which includes publisher policies that most of the odp.net installations include).
You can also install the 32 bit odp.net on your dev machine (ideally the same version again) in order to run/debug 32 bit applications or to use the integrated tooling that comes "with Oracle Developer Tools for Visual Studio" inside of Visual Studio.
All that said, there's more than meets the eye here. If you're application is in fact running (which is implied with "it's only a warning"), as 64 bit, than it is NOT using your 32 bit installation. I would guess your machine already has the 64 bit version installed (multiple oracle homes).
Another solution:
Download ODAC 11.2 Release 5 (11.2.0.3.20) and set your compiler to x86. I am 100 % sure it will clean all warnings related to oracle.
Set namespace to: using System.Data.Odbc;
Then make a database connection.
This is only a vs.net warning however is there any way to get rid of
this?
I believe there is no way to get rid of that, since you want to deploy on 32 bit machine and you create on 64 bit. This is just a warning that informs you that there may be sth wrong with the driver. Nothing to worry about if you now what you're doing.
You should expect it - you use 32 bit libraries on 64 bit architecture.
From the Oracle website here:
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
This is for their latest Oracle Data Access Components, 64-bit ODAC 11.2 Release 4 (11.2.0.3.0) for Windows x64. I want to use the developer tools (ODT) but they aren't available in 64 bit (probably because VS2010 is still 32-bit). From the site:
Important: The 32-bit Oracle Developer Tools for Visual Studio download is required for Entity Framework design-time features. The above download fully supports Entity Framework deployment, but does not contain design-time tools.
I don't use EF (I use the Mindscape LightSpeed product as it's usually 3 or 4 years ahead of EF) but the principle is the same - VS2010 and LightSpeed are 32-bit apps and can't load/use x64 libs.
I would like to use the 32-bit tools (ODT) to develop my app and deploy the app using the x64 ODAC. Has anyone done this? Can it be done? Anybody?
If it matters, this is for a WCF service running on a virtual Windows Server 2008 R2 machine. What I have done semi-successfully is force everybody to 32-bit operation, but that seems a little silly if 64 bit is supported as they claim it is.
Thanks in advance,
Dave
What the Oracle site mentions is that they have provided the ODAC components for both 32 and 64 bit, but have the Visual Studio design tools for only 32 bit.
Since you are not using EF, I am guessing you are interested in using ODP.NET components with LightSpeed.
For this scenario, you could go ahead by installing both 64 and 32 bit of ODP.NET on the development system and allowing the application to run in native mode on the deployment systems (the application will select the 64 or 32 bit ODP component based on the platform it is running on).
Check RealFiction blog and Semaphoremd blog for detail about installing the client tools for both 64 and 32 bit in parallel. Basically proper way to go about installing them in separate folders and creating symbolic links to the appropriate folder from %windir%\system32 and %windir%\SysWOW64. Thus allowing the WOW64 to take care of allocating the proper components based on the running application.