0

I have 3 projects in my solution:

Data.Mysql, Data.Progress, and MainProject

MainProject uses both Data.MySQl and Data.Progress.

Data.MySQL uses the Pomero-Provider and EFCore 3.11

Data.Progress uses an OpenEdge-Provider and EFCore 2.1.11

The Problem is that Data.Progress tries to use the EFCore 3.11 DLL.

First I noticed that only the 3.11 DLL was created in the output folder.

My first change was adding DestinationSubDirectory to seperate both projects and put them into subfolders:

<ProjectReference Include="..\Data.MySQL\Data.MySql.csproj">
  <Project>{050aeca0-c549-43b9-9fed-2cb3311a7239}</Project>
  <Name>Data.MySQL</Name>
  <DestinationSubDirectory>Data.MySQL\</DestinationSubDirectory>
</ProjectReference>
<ProjectReference Include="..\Data.Progress\Data.Progress.csproj">
  <Project>{c8972134-c3bf-4fab-9a35-7d496f464a14}</Project>
  <Name>Data.Progress</Name>
  <DestinationSubDirectory>Data.Progress\</DestinationSubDirectory>
</ProjectReference>

as well as adding this to the App.config

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath="Data.MySql;Data.Progress" />
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.EntityFrameworkCore" culture="neutral" publicKeyToken="c5687fc88969c44d"/>
            <bindingRedirect oldVersion="0.0.0.0-2.1.14.99999" newVersion="2.1.11"/>
            <bindingRedirect oldVersion="3.0.0.0-3.2.0.0" newVersion="3.1.9"/>
            <codeBase version="2.1.11" href="Progress\Microsoft.EntityFrameworkCore.dll" />
            <codeBase version="3.1.9"  href="MySql\Microsoft.EntityFrameworkCore.dll" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

One Problem is that Data.Progress does not create a EFCore DLL in the Data.Progress-Folder. So I copied the correct on into the folder manually.

I tried to Load the DLL manually when Data.Progress is used:

        string path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "/Microsoft.EntityFrameworkCore.dll";
        Assembly.LoadFile(path);

But Data.Progress is still trying to use the EFCore 3.1 DLL! What can I change to use the correct EFCore Version? I think it just tries to use the newest, loaded Version. Can I force it somehow?

Best Regards Christopher

Christopher G.
  • 1
  • 2
  • You can't mix multiple versions of the same assembly in the same executable. The real question is why are you trying to *downgrade* ? Whatever "Data.Progress" is, you'll have to upgrade it to use a recent version of EF Core. EF Core 2.1 is already two major versions behind – Panagiotis Kanavos Jan 04 '21 at 12:57
  • I need to access two different Databases. On uses MariaDB, the other is a ProgressDB. The EFCore Provider for Progress is not ready for EFCore 3 or higher and needs to use EFCore 2.1. The MariaDB(MySql)-Provider needs EFCore 3. – Christopher G. Jan 04 '21 at 13:00
  • ProgressProvider: https://github.com/alexwiese/EntityFrameworkCore.OpenEdge MySQLProvider: https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql – Christopher G. Jan 04 '21 at 13:01
  • 1
    You must downgrade and use EF Core 2 all over then – ErikEJ Jan 04 '21 at 13:05
  • You can't use a provider made for one major EF Core version with a different major version. You'll have to use EF Core 2 throughout, and use the appropriate EF Core providers. You should really, really, really rethink using an ancient database like [Progress](https://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Language#History). If you have a support contract, you can ask the vendor for a provider. The companies that acquired the 4GL products in the 200s though were more interested in the support contracts than new development. – Panagiotis Kanavos Jan 04 '21 at 13:16
  • In fact, [OpenEdge doesn't even have an ADO.NET provider](https://knowledgebase.progress.com/articles/Article/000028572), even though it's 2020. You should consider using a microORM like Dapper over an ODBC connection. Any OSS EF Core providers are doing the same but frankly, few people are willing or able to write and maintain providers for such edge cases. – Panagiotis Kanavos Jan 04 '21 at 13:21
  • @PanagiotisKanavos The ProgressDB is used and managed by our ERP-System and I need a faster way to access the data. That's why I'm bound to use or rather access the ProgressDB. – Christopher G. Jan 04 '21 at 13:25
  • That's unforutnate. I just linked to the official article saying they don't even have an ADO.NET provider, much less an EF Core provider. The provider you linked to is a third-party open source provider - someone in the same predicament as you implemented an EF Core provider for their own use, and released it publicly. If you want an EF Core 3 version, you should ask the maintainer of the OSS project. Your other options are to downgrade everything to EF Core 2 or use an OdbcConnection just for `Data.Progress` – Panagiotis Kanavos Jan 04 '21 at 13:32
  • Another option would be to clone the project and rebuild it using EF Core 3, fixing any compilation errors and taking care of any breaking changes. The [Gotchas](https://github.com/alexwiese/EntityFrameworkCore.OpenEdge#gotchas) section explains that Progress doesn't even have primary keys though, breaking a major requirement of all ORMs, not just EF Core. – Panagiotis Kanavos Jan 04 '21 at 13:37
  • @Christopher G. ,you can see the link [Using multiple versions of the same DLL](https://stackoverflow.com/questions/5916855/using-multiple-versions-of-the-same-dll) to use the correct version based on the condition. – Jack J Jun Jan 05 '21 at 02:52

0 Answers0