markrendle / Simple.Data

A light-weight, dynamic data access component for C# 4.0
MIT License
1.33k stars 303 forks source link

Multiple ADO Providers found specify provider name or remove unwanted assemblies #402

Open digioz opened 5 years ago

digioz commented 5 years ago

I have an asp.net mvc project which uses 3 different database types depending on which one the user select (MSSQL, MySQL & Oracle). The project follows an Adapter/Repository pattern for it's code. You can see the source code here if it helps:

https://sourceforge.net/p/digioznetportal/codenew/ci/master/tree/Source/3.0.0.0/digioz.Portal/

The problem is in order for me to use both MSSQL and MySQL I have added a reference to both those nugets. But now when trying to get data, the Database.OpenConnection method throws this exception:

Multiple ADO Providers found; specify provider name or remove unwanted assemblies

How can I specify a specific ADO Provider at runtime? I didn't find any methods or constructors on the Database Object itself.

The code in question:

` public class MySQLData : IDataContext { private string connectionString; private Database Database;

    public MySQLData(string connectionString)
    {
        this.connectionString = connectionString;
        this.Database = Database.OpenConnection(connectionString);
    }

    IMenuRepo IDataContext.Menu()
    {
        var menuRepo = new MenuRepo();

        return menuRepo;
    }
}

`

Thanks, Pete

skironDotNet commented 5 years ago

You have it all wrong. In inversion of control, the Domain have repository interfaces. This DAL (Data Access Layer) depends on the Domain repository interface definition. You then use Dependency Injection to Select the DAL, the implementation can be all different for different database. Of course we can assume implementation is close to same so you can have DAL.Base where you put all common code LINQ queries etc. but in your project you should have something like

  1. Dal.Base
  2. Dal.MySql
  3. Dal.Oracle
  4. Dal.Sql
  5. Domain
  6. DI

Now 1 to be referenced by 2,3,4. and (1), 2, 3, 4 should have reference to 5. to have interface definitions form Domain. Dal.X will implement the interface. DI will inject implemntation of selected Dal to Domain. Despite DI being separate project. Domain still can drive which Dal to select during the initialization (switching DB during application lifetime makes no sense). Going back to nuget references. so 2. would have ref to MySQL connector 3. would have ref to Oracem and 4. to MsSQL, so you don't have a collision of "Multiple ADO Providers found; "

digioz commented 5 years ago

Thanks for the reply, and I appreciate your advise on IOC. The problem though is if I change the code to follow IOC principles in order to separate out MSSQL Provider from MySQL Provider, it throws the following exception:

Simple.Data.SimpleDataException Message=No Ado Provider found.

The issue is, the Root Desktop or Web Application that is referencing the isolated DLL requires a reference to the ADO assembly and Simple.Data core DLLs and won't work unless there is a concrete reference to it. I have even tried to change the Build folder for the Dal.Sql and Dal.MySql libraries, but even if the two DLLs exist in the same bin folder, regardless of if the parent application references them or not it still throws the same exception:

Multiple ADO Providers found; specify provider name or remove unwanted assemblies

So it seems it doesn't matter how much you abstract the DALs, the two ADO DLLs (Simple.Data.SqlServer.dll and Simple.Data.MySQL.dll) just do not like to co-exist. This brings me back to my original question: Is there a way to specify the Provider Name at Runtime on the Database Object?

Thanks, Pete

P.S. I have had no such problems when using Dapper. You can see a sample test project here:

https://sourceforge.net/p/digioznetportal/codenew/ci/master/tree/Source/3.0.0.0/ORM/DapperMultiDBTest1/

Ideally if I am able to I would like to get Simple Data working the same way, because it's a lot leaner than Dapper and doesn't require a SQL Query to be specified which is a huge plus.