I had made small c# program that use oracle database so I had to include
reference
Data.OracleClient
after releasing my project and move it to the working environment I got problem
which is missing the reference Data.OracleClient
why the Data.OracleClient won't be included within the release version of my project ?????
what should I have to do to force the including of that library which is necessary to let my project work sinces i am not able to copy the dll file to all PSs on my network ??
and if i used the
Oracle.DataAccess.Client
how i know the equivalent keyworks with this library ??
should I rebuild the whole project ?!
Data.OracleClient is a Microsoft DLL which is usually installed on each Windows PC, i.e. :NET Framework. However, it has been deprecated for many years and should not be used for new projects.
You may supply Oracle.DataAccess.Client with you application, however the Oracle Client must be installed on the target machine.
As an alternative consider to use the ODP.NET Managed Driver, you can download it from here: http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
In this case you have to supply only single DLL Oracle.ManagedDataAccess.dll
Related
I've read many questions and answers indicating that if I want to link my C# project against native libraries, I can't use AnyCPU platform target but must make separate 32- and 64-bit builds, each linked against the native DLL of the appropriate bitness.
This makes me wonder how the .NET Framework assemblies themselves are, or at least appear to be, built for AnyCPU. That is, when adding a reference to my GUI application, why don't I have to pick the 32-bit or 64-bit version of System.Windows.Forms? I thought this might just be some Visual Studio magic that would resolve to the appropriate GAC subdirectory (GAC_32 or GAC_64), but I searched for System.Windows.Forms.dll in the GAC and found it in:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
Note the "GAC_MSIL". So how does this DLL manage to wrap a native 32-bit API yet remain linkable in a 64-bit application? And why can't I use a similar strategy to make a single C# DLL that links against a native 32-bit library yet remains runnable in 64-bit mode?
Option 1: In GAC you may register 2 versions of assembly one 32 and one 64 bit with exactly same names. Oracle DB Driver for .NET uses this strategy.
Option 2: With your assembly that will be AnyCPU deploy two versions of native DLL and choose proper DLL at runtime (SQLite works like that). As it turns out .NET Framework is intelligent enough to load proper version of native DLL via P/Invoke (Using a 32bit or 64bit dll in C# DllImport)
I had the same problem and ended up using Fody Costura
DLL Files will be shipped as embedded ressources and the lib takes care of the bitness.
You could find an example for SQLite here
The problem I have encountered was that your application needs to have access to the Windows Temp folder to create the assemblies from the ressource. If you dont need it, you could disable it using a config setting createtemporaryassemblies
I have ConsoleApplication01, ConsoleApplication02, ConsoleApplication03 and using "Mydll.dll" for accessing database.
I want to keep all "exes" of all Console Applications in one folder to run using windows service. So problem is that, Its asking to replace "Introp.Mydll.dll" into my destination folder.
Will it work by Replacing this file "Introp.Mydll.dll".
If its exactly the same dll (same binary) than there is no problem.
If you are using different versions for each application (and there is a good chance you should, or at least be able to, to allow upgrading the version only for a single service), you can use GAC mechanism.
GAC is sort of a centralized storage of a lot of dll's used by .net, and its uniqueness is that you can publish a lot of dll's with the same name that will have different versions or different globalization culture. That way your C# services will find the dlls and load them automatically from GAC, and if you will require to upgrade the dll just for one service, you will only change this reference to point to the new specific version.
You can read about GAC here:
https://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx
and how to install assembly (dll) into GAC here:
https://msdn.microsoft.com/en-us/library/dkkx7f79(v=vs.110).aspx
I am trying to make a setup for a C# application in .NET 3.5.
The application runs an other application which was compiled for .NET 4.5 and uses some DLLs. I want to add this application to the application folder in the setup.
I can't add the DLL's to the setup as a file, there is an error popping up. ("The operation could not be completed")
If I add the DDLs to the project folder and then use them as content, I get an "Unrecoverable build error" when I create the project.
How am I supposed to add these DLLs? I do not care how, but I need them in the project folder.
Thanks.
PS: I am using the standard setup for VisualStudio 2008.
With Visual Studio, when you add your external DLL as a reference in a project, it will automatically be added to the setup.
First of all, isn't there any way to find an earlier version of the assembly targeting .NET 3.5? Or if you have access to the source, remove/change the .NET 4.5 specific code and recompile?
Otherwise, you can try to wrap you dll around a COM interface, as described here. This article targets .NET 4 dll used with .NET 2.0 but the mechanism should still work in your configuration. I have used it successfully myself for 2.0/4.0 interop.
Here is another trick you can try.
Consider that in either case you will need .NET 4.5 installed on target computer, in order to work. So you can move your project from 3.5 to 4.5. I understand that you use VS2008 which doesn't have .NET 4.5, but you can use express (free) edition of Visual Studio from here -> Microsoft Download Page
I solved this problem using a simple trick:
The errors came only from the DLLs written in .NET 4.5. The executable (.exe) did not cause any errors. What I did is to package all the DLL's into the exe using the ILMerge tool.
Then I added the .exe file to the library and everything worked like a charm.
ILMerge download site (Microsoft)
First of all, I want so say I read the other questions and none of them helped me.
The server where I'm getting this error is a Windows 2003 SP2 + .net framework 4.0 + Oracle i9 client
I have downloaded the latest ODP.NET ODAC1120320Xcopy_32bit.zip a copied these dll out.
oci.dll
ociw32.dll
Oracle.DataAccess.dll
orannzsbb11.dll
oraocci11.dll
oraociei11.dll
OraOps11w.dll
I've created a little app which just connects to an oracle. link
And when I run this app I'm getting the The provider is not compatible with the version of Oracle client error.
On the download page was also written : Each 32-bit ODAC client download below supports connectivity to Oracle Database versions 9.2, 10.1, 10.2, and 11.1, and 11.2.
So I guess I should be fine with my 9i database.
I'm not sure if I should use some older ODP.NET version. One answer here on SO sugested to use version 11.1.0.6.20 which supports the .NET 2.0 but my application is written against .NET 4.0.
What can I do ?
I'm unaware of any supported method of running an oracle client without some sort of install (the xcopy version includes a batch file for installation so the "xcopy" is a bit of a misnomer.
That said, if you're going to do something that's unsupported, you might as well go with something that WILL eventually be supported - the 100% managed provider (meaning no extra unmanaged dlls to copy) is currently in beta:
http://www.oracle.com/technetwork/database/windows/downloads/odpmbeta-1696432.html
I am suborn to see something to the end even for just the learning experience so I'd understand if you wanted to see your current way to fruition. The oracle documentation does indicate that the application directory is in fact first in the unmanaged dll search order. My guess is that additional dlls are needed (you are using a newer version than your linked article). I would see which specific dlls it's loading from outside of your app directory using a tool like Process Monitor and see if you can find the equivalents from the new ODAC to copy over.
When I run any project from Visual Studio, it works excellent (on Motorola MC 3190 - WinCE 6.0)
However, when I install and run the application on the device, I get this error:
No compatible FusionInterface dll found, Expected version is 4.1.0.1 or higher version having the format 4.x.x.x
What could be the problem?
In my case, deploying Symbol.Fusion.dll and FusionInterface.dll files in the same directory than my executable has resolved this error.
You must install the symbol.all.arm.cab file. If you are using Windows CE then you need the armv4 version. If you are using Windows Mobile, then you need the armv4i version.
Also, make sure there is no local copy of the DLLs in your application's directory; this could be possibly causing a version mismatch.
Adding a reference to Symbol.ResourceCoordination worked for me. Per the CS_FusionSample1 code example included with the Motorola EMDK v2.9, the relevant Symbol references are Symbol, Symbol.Fusion, and Symbol.ResourceCoordination.
Note, I'm building for a Motorola 9190 handheld under Windows CE 6.0.
Fusion Interface DLL Version Compatibility
EMDK for .NET access Fusion Public API via Fusion interface DLL as mentioned in the Overview section. There can be different versions of Fusion Public API and in return many versions of Fusion Interface DLLs.
Version Incompatibility Issue
If this DLL is incompatible with EMDK, an appropriate meaningful error message will be provided in the exception when trying to access Fusion. This occurs when creating Config and WLAN objects.
Possible Messages
Older and incompatible FusionInterface dll 1.0.0.1 found. Expected version is 2.0.0.3 or higher version having the format 2.x.x.x
Newer and incompatible FusionInterface dll 3.1.0.5 found. Expected version is 2.0.0.3 or higher version having the format 2.x.x.x
Solution
The DLL version incompatibility arises because of the two files (Fusion Interface DLL and the Fusion Assembly DLL) taken from different EMDK packages. To fix the issue,
Method 1:
Remove "Symbol Managed Class Libraries" using "Remove Programs" in the control panel of the device.
Check "\Windows" folder of the device for any existence of "FusionInterface.dll" and if so, delete it.
Take the "symbol.all.arm.cab" from EMDK installed location, copy to the device and run installation.
The typical location is the appropriate sub directory (wce400\armv4 or wce500\armv4i) of "\Program Files\Enterprise Mobility Developer Kit for .NET\v2.x\SDK\Smart Devices".
Run the application.
Method2:
Copy the appropriate DLL to the \Windows directory of the device.
Run the application
Note: This DLL is not separately available in the EMDK for .NET package.