This project is read-only.
2

Closed

EDM fails to recognise our 64 bit EF provider for EF 6

description

we are developing an EF provider to support one of our databases. We have 32 bit EF provider which uses 32 bit db provider and it works fine. But we have some issues with our 64 bit EF provider which depends on 64 bit dbprovider. If we manually add reference to our EF provider in the application and keep the application process architecture as 64 bit, it works fine. But moment we use EDM to use Database First approach, EDM wizard fails with a message implying it was not able to find the compatible dbprovider. From our debugging, it appears the EDM is trying to create a AppDomain(as a 32 bit) and try to load the project exe(which is 64 bit) and in that process it fails complaining about a mismatch in process architecture. The Fusion Log is not showing any reference to our providers(EF or DB).

Any known issues or any clue as to what may be wrong here?

Any help or suggestion much appreciated.
Closed Dec 17, 2014 at 7:26 PM by RoMiller

comments

divega wrote Sep 25, 2014 at 2:59 AM

Note for triage: I had an opportunity to look at this in more depth today. Here is what is happening in more detail for this particular case:

Besides the traditional .config files EF6 supports registering an EF provider through code-based configuration (http://msdn.microsoft.com/en-us/data/jj680699). This feature is independent of whether you are using an EDMX model or Code First.

When the EF Designer needs to discover a provider from the application we need to do it in a way that can succeed regardless of how the provider was registered. The most general way to do this is to invoke the application’s code (using the ProjectExecutionContext) and give code-based configuration registration a chance to execute the registration code.

The limitation doesn't affect this particular provider because it is 64 bit. It actually affects all providers besides SQL Server with projects that are 64 bit only.

There are two alternatives to satisfy this request this:
  1. The simplest approach would be to create a fallback mechanism into VsUtils.GetModernProviderTypeNameFromProject() that can discover the provider services type from the project's configuration if the ProjectExecutionContext path fails. This would only solve the problem if the provider configuration isn't in code-based configuration.
  2. A more general but more complex approach would be to spin up a separate process instead of just a separate AppDomain to execute the user code.
My recommendation is to estimate the cost of #1. We should also be open to take that as a contribution.

BriceLambson wrote Nov 7, 2014 at 10:58 PM

Fixed in changeset c76104ccffbff12f182b3280b992eba196c3625b

ErikEJ wrote Nov 8, 2014 at 4:07 PM

@Brice Great fix, wonder if this makes the SQLite provider work with the EDM Wizard now, and if this solves #2562 ?