Some time ago we upgraded to Entity Framework 6 and we started to use code based registration of the EF provider.
Everything is fine and working but then we upgraded entity developer and dotConnect for Oracle on our development machines and everything went to hell (upgrade from 8.3.125 to the current 8.4 version).
Now, the developers who have dotConnect installed can ONLY run the newest version of our application. Any attempt to run older vesions (built against older dotConnect assemblies) will give an InvalidOperationException.
Code: Select all
No Entity Framework provider found for the ADO.NET provider with invariant name 'Devart.Data.Oracle'. Make sure the provider is registered in the 'entityFramework' section of the application config file. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.
We tried going away from code based registration thinking that this might have changed something, but to no avail.
It seems our only option is to add an assemblyBindingRedirect on our old releases that "downgrades" the assembly to the one we bundle with the application.
The next problem is of course that we have to override the policy because you guys for some reason insist on redirecting to the newest dotConnect version with the installed policy.
To make matters worse we have to redirect all "future" dotConnect releases as well (i.e. specific an invalid high version number in the redirect configuration), otherwise we risk breaking an old version the next time we upgrade dotConnect on the developer machines.
So in short, we have to add configuration clutter to our old releases JUST to make the developers be able to run the application. We could of course add management overhead and have a "developer.config" file for our developers, but unneeded overhead is best avoided!
Any ideas on how to get around this? it seems rather stupid because if we just remove dotconnect from GAC everything is working as intended. Can we get dotconnect nuget releases, or an installation alternative that does not deploy stuff to GAC?
We use quite a few third party developer tools, and while we cannot live without dotConnect it is the only third party tool that causes us such upgrade headaches (this is not the first time we have had multiple version issues like this one).