I'm building a set of components, let's call them services, that are using entity framework to access their data. Those components are designed to be used across several projects in the same solution. We would like to have these components as much as "independent" as possibile, meaning that we would like to upgrade, Entity Framework from 5 to 6 in one service and leaving EF5 on another. Our solution might look like this:
Solution
+- Application1 (referencing ServiceA and ServiceB)
+- Application2 (referencing ServiceA and ServiceC)
+- ...
+- ServiceA - Dll Using Entity Framework 5
+- ServiceB - Dll Using Entity Framework 5
+- ServiceC - Dll Using Entity Framework 6
With Application1 we have no problems as we can install EF5 as nuget package in it and have it used by both ServiceA and ServiceB, but what about Application2? I wasn't able to figure out a way to have both EF5 and EF6 on a project... And what about configurations? Is there any way to write configurations for ServiceA and ServiceB only once, and not having to repeat it for every single application using them? I'd prefer to avoid making ServiceA and ServiceB webservices and keeping all interactions between modules "in process".
Thank you in advance!
Further research convinced me that having two versions of EF in the same project is simply not possible. Not even desirable is to have multiple versions of EF in the same solution! My aim was to have "independent" services (something like DDD's bounded contexts) interacting "in process" each other and with applications, but this is not feasible.
To mitigate the configuration problem I guess I should rely on a "configuration service" or at least making most of the configuration via Code-Based Configuration (https://msdn.microsoft.com/en-us/data/jj680699.aspx) and shielding it as much as possible from the application.