Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: InterBase/Interfaces/Client    [ Add a report in this area ]  
Report #:  100618   Status: Open
ADO.Net 2.0 driver doesn't work with .Net 4
Project:  InterBase Build #:  9.0.4.443
Version:    9.0 Submitted By:   Nick Barrett
Report Type:  Suggestion / Enhancement Request Date Reported:  11/1/2011 1:09:32 AM
Severity:    Critical / Show Stopper Last Updated: 1/27/2012 5:01:02 PM
Platform:    Not OS or platform specific Internal Tracking #:  
Resolution: None (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: None
Description
The current version (15) of the ADO.Net 2.0 drivers for Interbase only work with .Net 3.5.  Would it be possible for the solution to be rebuilt for .Net 4?

We were experiencing the problem against Interbase 2007 and 2009.  I don't have an exhaustive list of build numbers but I can say for definite 9.0.4.443 at least as that is what I use for development.  The ADO.Net 2.0 driver itself, we were using your latest release I could find (file version 15.0.3890.34076).  As for the IDE, we were using Visual Studio 2010 on Windows 7 64bit.
Steps to Reproduce:
Please see comments of QC.
Workarounds
None
Attachment
None
Comments

Tomohiro Takahashi at 11/1/2011 9:24:07 PM -
What version of InterBase do you use, for example InterBase XE?

> ADO.Net 2.0 driver doesn't work with .Net 4
Could you tell us more detail about the issue? Do you get any error?

Nick Barrett at 11/2/2011 3:09:27 PM -
Thank you Mr. Takahashi for replying =)

Apologies for not providing enough detail.  I have spent the last hour and a half writing up a detailed description of what was going wrong and repo-steps only to find the solution to my own problem.  As such I will explain the symptoms of the problem and how to solve it in the hopes that it may helps others in the future.

We were experiencing the problem against Interbase 2007 and 2009.  I don't have an exhaustive list of build numbers but I can say for definite 9.0.4.443 at least as that is what I use for development.  The ADO.Net 2.0 driver itself, we were using your latest release I could find (file version 15.0.3890.34076).  As for the IDE, we were using Visual Studio 2010 on Windows 7 64bit.

First off, when I tried to use the ADO.Net 2.0 driver in a new .Net 4 console application I got the following error and warning:

Error
1
The type or namespace name 'Data' does not exist in the namespace 'Borland' (are you missing an assembly reference?)
C:\ConsoleApplication1\ConsoleApplication1\Program.cs
5
15
ConsoleApplication1

Warning
2
The referenced assembly "Borland.Data.DbxCommonDriver, Version=15.0.0.0, Culture=neutral, PublicKeyToken=91d62ebb5b0d1b1b, processorArchitecture=MSIL" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
ConsoleApplication1

My first attempt to solve this problem was to change the "Target framework" from ".Net Framework 4 Client Profile" to ".Net Framework 4".  The application would then compile, but when it ran and tried to open a connection to a database using a TAdoDbxInterBaseConnection I got the following error:

Could not load file or assembly 'Borland.Data.DbxCommonDriver, Version=15.0.0.0, Culture=neutral, PublicKeyToken=a91a7c5705831a4f' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I then changed the "Target framework" again, this time from to ".Net Framework 4" ".Net Framework 3.5".  The application would now compile and run.  This is when I decided that the problem was that the ADO.Net 2.0 driver would not work correctly with .Net 4 and I posted my first report.  As you (quite rightly) asked for more details I decided to write up exact repo-steps and in doing so changed the "Target framework" from ".Net Framework 4 Client Profile" to ".Net Framework 4" as the first step after creating a new "Console Application" in VS2010 only to find that the application worked correctly.  I then re-opened the my initial project and changed the "Target framework" from ".Net Framework 3.5" to ".Net Framework 4" and that worked too.

After some more testing I have come to the conclusion that in order to get the ADO.Net 2.0 driver to work you must either first change the  "Target framework" from ".Net Framework 4 Client Profile" to ".Net Framework 4" before your first compile in order for it to work (maybe even before adding references to the ADO.Net 2.0 driver).  If you do it after, then you must close VS2010 and re-open your solution in order for it work.  Simply changing the "Target framework" from ".Net Framework 4 Client Profile" to ".Net Framework 4" and then doing a "Rebuild Solution" won't work.

So apologies once again.  I hope this helps others who may fall into the same trap.

Cheers,

Nick Barrett

PS: Can I say that I find it strange that the ADO.Net 2.0 driver won't work with the "Target framework" set to ".Net Framework 4 Client Profile" when one would think that it is inherently something that could be used solely in a client application.

Sriram Balasubramanian at 1/27/2012 5:01:00 PM -
Nick,

Thanks for the detailed steps and workarounds you provide.

I checked with the RadStudio team about the "Client Profile" question, and got the following.

>>>
According to http://msdn.microsoft.com/en-us/library/cc656912.aspx, the .NET Framework 4 Client Profile provides a subset of .NET Framework 4.  From the error in the QC report I would guess that this Client Profile does not contain System.Web.  From the article that I linked above:

If you are targeting the .NET Framework 4 Client Profile, you cannot reference an assembly that is not in the .NET Framework 4 Client Profile. Instead you must target the .NET Framework 4. For more information, see Troubleshooting .NET Framework Targeting Errors.

The reference to System.Web is required by Borland.Data.AdoDbxClient.dll in order to provide support for SqlDataSource which is contained in System.Web.UI.WebControls (http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.sqldatasource.aspx).

<<<

Tomohiro Takahashi at 11/2/2011 6:13:24 PM -
Nick-san
if you need official reply from Embarcadero, could you please contact technical support service?
http://support.embarcadero.com/

Nick Barrett at 11/10/2012 7:31:26 PM -
Just wanted to write a quick note to say that I have found the workaround for QCR#87938 has worked for me.  
So instead of using:

DbConnection c = new TAdoDbxInterBaseConnection();

as is in the INSTALLATION AND USAGE INSTRUCTIONS that come with the driver, instead use:

DbConnection c = TAdoDbxInterBaseProviderFactory.Instance.CreateConnection();

Some other notes that may be useful:
1) As in the INSTALLATION AND USAGE INSTRUCTIONS, I added the following references to my C# .net 4/4.5 project:
  Borland.Data.AdoDbxClient.dll
  Borland.Data.DbxCommonDriver.dll
  Borland.Data.DbxInterBaseDriver.dll

2) The application/assembly will need access to the following additional files:
  dbxadapter.dll
  dbxint.dll
These are target cpu specific.  There are versions for 32bit and for 64bit.  At the moment I set my application/assembly cpu target to either x86/x64 and then use "Add Existing Item..." to add the appropriate files to the project.  You have to set the two files' "Copy to Output Directory" property to something other than "Do Not Copy".  I'm not sure this is the best way to deal with this but seems to work for now.

3) You will need to install the client drivers on the end-user's machine so that your application has access to gds32.dll or ibclient64.dll.  Either that or add the one you need to your project by using the method described in 2)

Hope this helps someone =)

Thanks to Tomohiro Takahashi for the workaround.

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.