Avoid framework lock-in with dependency inversion

Question

I am trying to understand the concept of dependency inversion and I think I finally got the concept. However now I am struggling with another issue, which is the selection of framework, when implementing it in .NET, at least.

Say I have a business logic assembly which has the need for a data access class. For that I add an interface for the data model and data access class in the business logic assembly (as shown in the drawing below). The actual implementation of the data access interface(s) is done in a different assembly (project).

This ensures that my business logic does not need to know anything about the implementation of the data access. However, it also means that if my business logic is implemented in .NET Core, then my data access assembly needs to be implemented in .NET Core as well.

Isn't there any way to avoid this, so I don't couple the framework of my data access assembly to that of my business logic application?

In other words, can I get the left part of my drawing to be in .NET Core and the right part to be in .NET Standard (for instance)?

Answer 1

First of all, I think you are confused about terminology. Two possible compilation targets are ".NET Framework" (owned by Microsoft and developed for Windows) and ".NET Core" (which is open source and cross-platform). ".NET Standard" isn't really a compilation target-- there is no such thing as an assembly "compiled in .NET standard." It is a specification to which a framework can comply. When a framework is compliant to .NET Standard, that means it supports a core set of functions that Microsoft has defined as essential.

Now to address your question. No, you cannot combine .NET Core and .NET Framework in a single process space, so the idea of injecting a dependency from an assembly compiled against a different framework is simply not possible (and if it were, it'd be really confusing).

The way this sort of problem is solved is via recompilation. You compile the code under the framework you need, and if you want to switch frameworks, you recompile. Since different frameworks support different things, you may have to modify some of your code for recompilation to succeed. But if all of your code sticks to .NET Standard, that shouldn't be an issue-- that is exactly why it was invented.

Answer 2

You can mix and match, but you may get a lit of runtime DLLs added to older .net projects. See here for examples

https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET