Can I use 32 bit Oracle Developer Tools with x64 ODAC in VS2010? - visual-studio-2010

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.

Related

How to connect .net API to MS Access database

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.

Choose 32 bit or 64 bit reference dll depending on environment in Visual Studio

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.

File-based database engine

I'm looking for a relational database engine that complies with the following requirements:
Databases are simple files like MSAccess databases. You can copy, delete, send them easily just with Windows Explorer. There's no management tool required.
x86 and x64 database providers can coexist on the same machine. MSAccess meets this criterion if you use the Jet 4.0 database format. Then you can use Windows' built-in Jet 4.0 (Microsoft.Jet.OLEDB.4.0) for 32 bit access and Access 2010 Database Engine x64 (Microsoft.ACE.OLEDB.12.0) for 64 bit access. But if Office 2010 is installed in its 32 bit edition, Microsoft prevents you from installing ADE x64. Since many customers actually need Office 2010 x86, switching to the x64 edition is not an option.
Database files can reside on a network share. Concurrent access is not required, but the engine must be able to open databases that are not local.
Could SQL Server 2012 Express LocalDB work out?
Access (Jet 4.0) databases comply with most scenarios, but the aforementioned limitation (2.) stands. However, if Microsoft released Access 2013 Database Engine x64 as a standalone redistributable in future, this might solve this issue. Since Office 2013 introduced the Microsoft.ACE.OLEDB.15.0 provider, evidence suggests that Office 2010 x86 and ADE 2013 x64 actually can coexist. Does anyone know if this will eventually happen?
Have you checked out SQLite? That may be worh a try.

Including sql server compact in desktop install for win 7 32bit and 64bit

I have a desktop app created in vs10 and am using clickonce install. I must include a database with critical info for the program as part of the install. I am compiling for all versions of windows (32 and 64). But as I understand it, if I include the 32 bit sqlce as part of the installation, it will not work on 64 bit installs. Must I include a 32 bit and 64 bit version of the db and test for windows version before accessing the data? Or is there a simpler solution that I am missing?
You can just include all the required files as content with your app, and it will run for any user and on both x86 and x64 platforms. Just follow the instructions here: http://erikej.blogspot.com/2011/02/using-sql-server-compact-40-with.html

Oracle .NET Provider DLL hell

I am currently developing on a Win7-32bits computer. Everything works fine. It's a ASP.NET application.
I was able to use Microsoft's Oracle deprecated .NET provider to connect to Oracle (using 32 bit instant client) and also ODP.NET. No problems at all. Application runs fine.
The problem comes when I deploy it to IIS7 on Windows 2008 Server 64bit computer. I can't get Microsoft's deprecated .NET provider or ODP.NET to work easily.
Is there a straightforward way to use a 32bit based ODP.NET or Microsoft's Oracle deprecated .NET provider in Windows 2008 Server 64bits?
DLL hell here!
Thanks.
Have you tried creating a 64bit version of your software and deploying with the x64 version of ODP.NET?
See this answer for Visual Studio configuration details.
Since this question is unanswered I'll add a link to another answer I created a while ago even though this question is very old.
Is ODP.NET required for Oracle 11g Client?
In general, change to Oracle.ManagedDataAccess (the managed code version of the ODP.NET client made by oracle) instead of the non-managed alternatives. This will help you a lot with "bittyness".
if you set IIS to run 32 Bits then I can confirm that the odp.net driver should work without problem as long as it's the 32 bit client. http://support.microsoft.com/kb/894435.
I've done this in iis for websites in the recent past and for our winforms app have set it to be x86 build so we always get the 32 bit odp providers on a 64 bit os (though you can do it with corflags as well).
Cheers,
Crocked

Resources