Could not load type 'CoreLab.Common.DbConnection'

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
Daria
Posts: 4
Joined: Fri 09 Mar 2007 16:29

Post by Daria » Fri 09 Mar 2007 16:35

We are getting the
Could not load type 'CoreLab.Common.DbConnection' from assembly 'CoreLab.MySql, Version=3.50.13.0, Culture=neutral, PublicKeyToken=09af7300eec23701'.

error. It is a 2.0 framework project with a couple 1.1 dependencies. We have a couple of test machines and one production machine. This error does not occure on my local machine, or on our local test machine. It does, however, occure on our remote test machine and on production. I did a binary compare of all the files on our local testing machine compared to what is on our remote testing machine. The code was the same.

Where else can I look for what is causeing the issues on some machines but not on others.

Thanks,
Daria

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

Post by Alexey » Mon 12 Mar 2007 08:55

Please check what modules are loaded from what .NET Framework. Probably System.Data is loaded from .NET Framework 2.0, but CoreLab.Oracle.dll is loaded from from .NET Framework 1.1 and base class for 'CoreLab.Common.DbConnection' is not found.
Last edited by Alexey on Mon 26 Mar 2007 06:42, edited 1 time in total.

Daria
Posts: 4
Joined: Fri 09 Mar 2007 16:29

Post by Daria » Mon 12 Mar 2007 16:28

What we ended up doing over the weekend is making 2.0 copies of all our 1.1 project references. This did not help.

If the System.Data is loaded from .NET Framework 2.0, but CoreLab.MySql is loaded from .Net Framework 1.1, then how can the same code be working on a different machine? I compared every file in the project folder.

I cannot find the post now but there was a similar posting where the person just ended up changing something in the machine.config. Unfortunatly he did not say what he changed. Maybe you know what it could be?

Thanks,
Daria

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

Post by Alexey » Wed 14 Mar 2007 10:46

We have reproduced this problem and analyzed it. If you have a project created for .NET2.0 framework with references to CoreLab.Oracle.dll for .NET 1.1 framework you should remove appropriate assembly from the .NET 2.0 GAC, so that it wouldn't be loaded.
Last edited by Alexey on Mon 26 Mar 2007 06:43, edited 1 time in total.

Daria
Posts: 4
Joined: Fri 09 Mar 2007 16:29

Post by Daria » Fri 23 Mar 2007 15:43

So here is what we noticed on our end. The two machines that the site works on both have a 1.1 CoreLab entry in the C:/WINDOWS/assembly folder. The two machines that this does not work on do not have this GAC entry.

We are thinking that our build process uses the GAC entry of corelab instead of what is in the bin folder. Our build machine also has a GAC entry for the old corelab. Our build machine builds 1.1 project as well as 2.0 projects we have about 15 differenct projects 2 of which are 2.0.

I don't think we can delete the GAC entry because from what I remember the build machine has to have CoreLab installed for it to work. And the corelab program is what uses the GAC and so we cannot uninstall the GAC entry.

Is there anyway to have both a 2.0 and a 1.1 corelab installed?

If you have the 1.1 and 2.0 framework installed how does the corelab installation process know which corelab to install? http://www.crlab.com/mysqlnet/ I noticed on this page that the framework is a requirement before installing mysqldirect.

Do we need to have two build machines? One for 2.0 projects and one for 1.1 projects?

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

Post by Alexey » Mon 26 Mar 2007 14:11

Is there anyway to have both a 2.0 and a 1.1 corelab installed?
Of course. There is no problem in having both versions on the same machine.
If you have the 1.1 and 2.0 framework installed how does the corelab installation process know which corelab to install?
There two packages of Core Lab MySQLDirect .NET. One for .NET 1.x and another for .NET 2.0.
Do we need to have two build machines? One for 2.0 projects and one for 1.1 projects?
I don't think so. The problem is that you don't refer to CoreLab.MySql.dll for the appropriate framework. If you have a project for .NET 2.0 Framework, then use our assembly dedicated to .NET 2.0.

Daria
Posts: 4
Joined: Fri 09 Mar 2007 16:29

Post by Daria » Mon 26 Mar 2007 14:47

We finally found the solution.

We had to install Corelab 35 for .NET 2.0 on the build machine. We had checked and rechecked all out references before doing this and they were all pointing to the .NET 2.0 dll but they were still getting built with the 1.1. After the install everything worked.

Hopefully this helps someone else out in the future.

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

Post by Alexey » Mon 26 Mar 2007 15:27

Well done.

Post Reply