Issues with multiple dotconnect versions and EF6

Discussion of open issues, suggestions and bugs regarding Entity Framework support in ADO.NET Data providers
Post Reply
esben
Posts: 43
Joined: Tue 05 Jul 2011 09:40

Issues with multiple dotconnect versions and EF6

Post by esben » Fri 17 Oct 2014 08:44

Hi

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.
This only affects the developers with dotConnect in GAC.
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).

Shalex
Site Admin
Posts: 8247
Joined: Thu 14 Aug 2008 12:44

Re: Issues with multiple dotconnect versions and EF6

Post by Shalex » Fri 17 Oct 2014 12:03

esben wrote: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.
Please remove the policy.*.Devart.* files from your GAC: http://forums.devart.com/viewtopic.php?t=29352. This should fix the problem.
esben wrote:Can we get dotconnect nuget releases, or an installation alternative that does not deploy stuff to GAC?
NuGet packages are available only for Express edition of dotConnect for Oracle (http://www.nuget.org/profiles/Devart/). Installation as NuGet packages cannot be done for licensed versions of dotConnect for Oracle, because this would break the .NET component licensing approach which is recommended by Microsoft and used in our provider (http://www.devart.com/dotconnect/oracle ... nsing.html). Also NuGet package doesn't allow to enable the design time features of dotConnect for Oracle.

esben
Posts: 43
Joined: Tue 05 Jul 2011 09:40

Re: Issues with multiple dotconnect versions and EF6

Post by esben » Fri 17 Oct 2014 13:31

Ill give it a try with removing the policy files. Thank you!

Could we get an "advanced" installer option so we can avoid the policy files altogether?

Even though it seems counter intuitive (and probably a big breaking change), you could change to a variety where the assembly version was part of the name. Like Devart.Data.Oracle.8.4.dll for all 8.4.x versions - this is what DevExpress does, allowing them to have side-by-side version while still keep the option of doing bug/security fixes for a specific version.

Anyway just an idea to get around the issue of keep multiple versions at the same time.

Pinturiccio
Devart Team
Posts: 2192
Joined: Wed 02 Nov 2011 09:44

Re: Issues with multiple dotconnect versions and EF6

Post by Pinturiccio » Wed 22 Oct 2014 14:43

esben wrote:Could we get an "advanced" installer option so we can avoid the policy files altogether?
Unfortunately, we cannot create an installer that does not add policy files to GAC. You need to manually delete Devart.* and policy.*.Devart.* files from the GAC. You can also create a .bat file that deletes Devart.* and policy.*.Devart.* files from the GAC.
esben wrote:Even though it seems counter intuitive (and probably a big breaking change)
You are right, this would be a big breaking change.
esben wrote:Like Devart.Data.Oracle.8.4.dll for all 8.4.x versions - this is what DevExpress does
Our version policy differs from the one of DevExpress. Currently we don't plan to change it.

Post Reply