Issues with multiple dotconnect versions and EF6

[esben]

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]

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.

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]

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]

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.

Even though it seems counter intuitive (and probably a big breaking change)

You are right, this would be a big breaking change.

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.