DB2 IBM .NET Provider for .NET Core - c#

I've added the latest .Net Provider for DB2 to my project. It seems to add half of IBM's source to my project :|
Seriously, there is an almost 80MB clidriver folder in there now. I'm assuming IBM still hasn't gotten around to making this provider fully managed after 20 years.
Do I need this folder when I deploy the code? What about for .Net Core? Do I need to build it separately for Linux?
The docs aren't great on what this is for.

Related

.Net Core MySql

I've just started coding in Visual Studio Code with .NET Core, on Ubuntu 14.04.4
I'm used to both using Ubuntu (from personal interests, hobby, etc) and .NET and Visual Studio at work.
But I've run into a problem i can't seem to overcome. I'm building a small console app that i want to communicate with a MySql Server, but I can't seem to get the MySql.ConnectorNET.Data working properly.
It was installed with the command dnu install MySql.ConnectorNET.Data And that seemed to work fine. The dependency was added in the project.json file, and intellisense was able to traverse the package just fine, but the OmniSharp Log reports that:
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Project /home/<username>/VSCode/SimpleSQLatmpt/project.json has these unresolved references: MySql.ConnectorNET.Data
and I simply can't seem to fix that. VSCode seems to detect it, and asks me to run the dnu restore command. But it's to no avail. For all intends and purposes it seems like MySql.ConnectorNET.Data is available in the project, but just can't be used.
Can any one tell me how to fix this?
And just as important, why it is happening in the first place?
Thank you very much for your time.
At the time of this question (Mar 2016) there was no .NET Core-compatible ADO.NET provider for MySQL.
Now situation is changed:
MySqlConnector written by Bradley Grainger -- licensed under MIT, and offers full async support
MySql.Data (>6.10) provided by Oracle (traditionally, GPL)
Personally I prefer MySqlConnector -- it can be used in commercial projects for free (MIT license); also I've tested it with my NReco.Data library under Linux, and it works perfectly in my scenarious. Unfortunately, MySqlConnector doesn't support EF Core yet.
--- UPDATE --
One more .NET Core-compatible MySQL connector + EF Core MySQL provider:
Pomelo.Data.MySql (unfortunately it doesn't implement true async behaviour)
Pomelo.EntityFrameworkCore.MySql
UPDATE 2
MySql Connector NET for .NET Core 1.0 was just released (Sep 2016)
http://insidemysql.com/mysql-connector-net-for-net-core-1-0/
I didn't try Bradley Grainger's connector, but this one from MySQL do not support SSL. :(
So, anybody who wants to use anyway, should connect with ";SslMode=None;" in the connection string.

Is it safe to uninstall MySQL Connector if I'm using it as a reference (Visual C#)?

I'm in the process of developing an application that interacts with a MySQL database. Because it interacts with some older software, it has to be built in .NET 3.5.
Another application I'm developing was made from scratch and doesn't talk to anything other than MySQL. Therefore I built it with .NET 4.5.
I have the latest version of the MySQL connector installed on my developing machine to work with .NET 4.5, but 3.5 doesn't like it because the connector requires 4.5.
Here are my questions:
Is it safe to uninstall the newer MySQL connector, since the reference DLL's have already been copied to that project, without breaking my 4.5 project?
Is it a better idea to just run both off of the older connector version?
I'd test this out myself but I'm in a position where I don't have admin rights. I have to bother IT anytime I want to do anything, and they generally like it if I know what I'm doing before I go talk to them.
Thanks all.
In case anyone else stumbles upon the same issue:
You can run both applications off of the old framework, even if one is built with .NET 4.5 it can handle the old MySQL connector framework. I have yet to experience any issues with version compatibility between the .NET 4.5 project and the connector built for 3.5.
You will have to make a new reference to the older framework, however - once the new MySQL connector is uninstalled your applications that rely on it will cease to function until you install another version and reference that one.

ODP.NET: The provider is not compatible with the version of Oracle client

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.

Ado.net provider 2.0 for .C# .net provider 4.0

I am using Sqlite ADO.NET provider 2.0 in my c# application .net framework 4.0.
Question1: Does this .dll come with a back up Database functionality?. If the suer wants to backup, looks like I have to get the source code and write my own backup feature.
Or is it already provided and I just need to use it?
Question2 :
I tried downloading a recent version of Sqlite ADO.NET provider(line 3.5/4.0)
from this website
http://www.sqlite.org/download.html/
sqlite-dll-win32-x64-3071300.zip
After attaching the dll as reference, it still says
Version v2.0.50727.
Description: ADO.NET 2.0 Data Provider for SQLite. Is this correct stable version or is there a recent one to be used.
Thank u
For Question 1: The ADO.NET provider isn't meant to have a backup capability. That's something the RDBMS software should have. ADO.NET is just a tool used to simplify communicating with the RDBMS.
- However, SQLLite backups are documented at http://www.sqllite.org/backup.html
For #2 I don't see a question - just a statement that you got a warning from Visual Studio. BUT based on what I'm seeing, you will get an error. You're trying to use an SqlLite provider for .NET 3.5 or above, and your .NET project is set to 2.0. Either upgrade your app to 3.5 or above, or look for an older .dll to download and use.
As a general rule of thumb, in a .NET project, you can use .dll files specified for an older version of the Framework, but not .dlls specified for newer versions.

Problems when deploying small .NET 3.5 apps

I wrote some small apps using .NET 3.5 but now I am stuck with deployment problems. My customer will likely to be pissed off when he learns that he will have to download a 231megs dependency (.NET framework 3.5) which installs for 30 minutes (!!!) on an average machine. All, just to run my tiny apps.
Offline distribution is also problematic, since the customer wants the program to fit on a Mini CD (185 mega bytes maximum)
What can I do? I really like .NET, but now I feel hopeless. With almost any other choice (c,c++,python) I would have saved this headache.
update: this is small data processing software and mostly deployed in offline situations on nettops. I can't host is from the net.
You can use the .NET Client Profile installer instead of the full framework. Should be around 28MB and be a pretty quick install.
http://blogs.windowsclient.net/trickster92/archive/2008/05/21/introducing-the-net-framework-client-profile.aspx
Perhaps you should target the .NET 2.0 framework until your clients are ready to upgrade. Even if you weren't using .NET you will still have these headaches. If you were using Python you would still have to ensure that the user had the proper version of Python installed.
You should try it with the compact .net framework it's only 34mb big, and should be able to be installed quite quickly.
Please remember if you use the .NET setup bootstrapper application, it will only download the parts of the .NET framework that it needs. Usually less than 100mb, in a worst case scenario where they don't even have .NET 2.0 installed.
Also, depending on your application you may be able to use the .NET 3.5 Client Only framework, it is considerably smaller, however I do not know if there is a offline download for it.
You can set your application to use the Client Only framework from the project properties, just check the "Client Only framework subset" checkbox.
This won't work if your application uses WPF or WCF, I think. I'll update this later if I find out I am wrong.
EDIT:
One more option is to use something like Xenocode Postbuild or Xenocode Virtual Application (http://www.xenocode.com) studio to embed the .NET framework into your application so that the client would not need to have .NET installed on each machine.
However, this will make your application exe much larger. A project I work on uses Xenocode Postbuild to embed the .NET framework 3.0 and the exe size ends up being around 50mb, however, the app runs great off of a flash drive.

Categories

Resources