Problems with OraDirect and DbProviderFactories.GetFactory

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Problems with OraDirect and DbProviderFactories.GetFactory

Post by murfdude » Tue 18 Jul 2006 20:33

Can someone provide a complete example demonstrating how to code a generic, factory-based implementation using OraDirect 3.5.9?

I have added the following to the machine.config under :



This causes the OraDirect provider to show up in the DataTable returned by DbProviderFactories.GetFactoryClasses(). However, when it comes to creating a DbProviderFactory using DbProviderFactories.GetFactory("Corelab.Oracle") the system throws an ArgumentException with the message "Unable to find the requested .Net Framework Data Provider. It may not be installed."

Any help would be greatly appreciated. Thanks in advance!

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Wed 19 Jul 2006 08:04

Invariant name of a provider is "CoreLab.Oracle".

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Wed 19 Jul 2006 17:29

Correcting InvariantName did not solve the problem. However, during troubleshooting I discovered the license file was not included in the assembly. This corrected the issue on the development machine. Unfortunately, I am now having a different problem with the deployed solution.

The entire contents of the \bin\debug folder including the CoreLab.Oracle.dll file was copied to a non-development machine. As on the development machine, the OraDirect generic provider was defined in the DbProviderFactories section of the application's .exe.config file. No license files were deployed.

When the deployed application attempted to create a DbProviderFactory an exception with the message "The requested .Net Framework Data Provider's implementation does not have an Instance field of a System.Data.Common.DbProviderFactory derived type." was thrown. The CoreLab.Oracle.dll file was then added to the machine's GAC with the same result.

Any thoughts?

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Thu 20 Jul 2006 06:36

Make sure that appropriate section is added to machine.config on the non-development machine as well.

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Thu 20 Jul 2006 12:15

Referencing my previous post, "As on the development machine, the OraDirect generic provider was defined in the DbProviderFactories section of the application's .exe.config file." We prefer not to deploy to the machine.config, using the application config file instead. This works fine on the development machine. I will do some further testing with this in mind but really don't think that's the problem. Can you suggest anything else I might check?

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Thu 20 Jul 2006 13:10

Check that our assembly is in the accessible place.

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Thu 20 Jul 2006 19:38

Alexey,

A previous post states "The entire contents of the \bin\debug folder including the CoreLab.Oracle.dll file was copied to a non-development machine." The CoreLab.Oracle.dll was copied to the same folder as the application executable. Do you have any other suggestions?

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Wed 26 Jul 2006 09:03

We do not experience such problem here.
Could you send us a test project if possible to reproduce the problem?

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Mon 07 Aug 2006 14:48

The project files can be downloaded from here:

http://www.flnet.net/files/orasimple.zip

This version uses OraDirect 3.50.9 but 3.50.11 produces the same result. The call to DbProviderFactories.GetFactory throws an exception with this text: "The requested .Net Framework Data Provider's implementation does not have an Instance field of a System.Data.Common.DbProviderFactory derived type." Using the OraDirect objects directly does not produce the error.

I have tried this with the CoreLab.Oracle.dll file in the application folder and in the GAC. The results are always the same. The application works when run on a machine where the OraDirect setup was run and fails on all others.

This should be fairly simple to recreate. Just install the .NET Framework 2.0 on a machine on which the OraDirect setup has NOT been run. Then, expand the zip file, compile the application and copy the \bin\debug folder to the test machine.

Paul
Posts: 725
Joined: Thu 28 Oct 2004 14:06

Post by Paul » Tue 08 Aug 2006 13:21

We cannot reproduce the problem with your example, OraDirect .NET 3.50.9, .NET Framework v2.0.50727. Everything is correct and works in our environment.

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Tue 08 Aug 2006 13:47

Was OraDirect installed on your test machine using the installer? If so, it will work every time. What we are attempting to do is xcopy deploy the CoreLab.Oracle.dll file into the application folder without running the installer. This works fine when not using the generic data objects but fails using the factory approach.

Paul
Posts: 725
Joined: Thu 28 Oct 2004 14:06

Post by Paul » Wed 09 Aug 2006 11:28

Yes, it works without installing OraDirect .NET. You have to add the following to (Windows folder)\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
and add CoreLab.Oracle.dll to GAC. Please note that "type" parameter is different from your post, we recommend to use it with OraDirect .NET, but your example works with your registration information.

The correct path to this tag in machine.config is

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Thu 10 Aug 2006 13:50

The following text was inserted into the prescribed position in the test machine's machine.config file. Other than the version number in the description, the text is exactly like that inserted into the development machine's machine.config file when OraDirect 3.5.0.11 was installed.
Following the machine.config modification the test computer was rebooted and the application was run again. The results were exactly the same. The call to DbProviderFactories.GetFactory throws an exception with this text: "The requested .Net Framework Data Provider's implementation does not have an Instance field of a System.Data.Common.DbProviderFactory derived type." As before, a direct connection using OraDirect without the generic factory implementation worked fine. The test was repeated again after adding all the strongly named CoreLab dlls from the application folder to the GAC and rebooting (just in case). Again, the result was the same.

In addition, the development machine ran the same test code successfully after removing the reference to OraDirect in the machine.config. This seems to indicate that the presence or absence of the OraDirect definition in machine.config or app.config has nothing to do with the problem. This makes sense, since the code in the sample should rely entirely upon reflection to find the required assembly.

There must be something else in the install process that affects the usage of generic data access factories. Can someone check with the folks that created the installer? Perhaps they can shed some light on what takes place during a standard install that might affect this.

Alexey
Posts: 2756
Joined: Mon 13 Mar 2006 07:43

Post by Alexey » Fri 18 Aug 2006 08:48

Let's cross the "t"s:
What version of Visual Studio do you use?
Specify your hardware architecture: x32 or x64?
What was the name of OraDirect installation package?

murfdude
Posts: 12
Joined: Fri 24 Mar 2006 14:09
Location: Florida, US

Post by murfdude » Fri 18 Aug 2006 12:23

What version of Visual Studio do you use?
VS Team Suite 2005

Operating System:
WinXP Pro SP2

Specify your hardware architecture: x32 or x64?
P4 32 bit, 1GB RAM

What was the name of OraDirect installation package?
oranet350pro2.exe, version 3.50.11

Post Reply