Question posted in 
I know that I can’t be the only one with this problem but my googling simply hasn’t provided anything fruitful. I may be missing some key word. Anyway, here’s the issue:
We are developing a C# program that utilizes a third party backend. We can’t substitute this backend for something else, no matter what.
The API for this backend is provided by the backend manufacturer in the form of two DLLs and is currently built on .NET Framework 4.6.1 and will soon be upgraded to .NET Framework 4.8. In a year or two it most likely uses something else as 4.8 is the last version of .NET Framework.
Most of our program is about a lot of other stuff that we would love to be able to code with something newer than .NET Framework 4.8, e.g., .NET 6 or 8.
So now my question is, how can we have a Visual Studio solution with different projects where one targets .NET Framework 4.8 and others target .NET 6, say?
(Imagine a car manufacturer without a factory trying to automate the complete car design process in .NET 8.0 but ultimately having to ask some external factory that only speaks .NET Framework 4.8 to build the car.)
I have previously had solutions with a .NET Framework 4.7.2 project and a .NET Standard 2.0 project, but these are compatible. What if I have two incompatible versions of .NET? I’m hoping that there is some sort of go-to architecture or design pattern that can be used here. I’m guessing it can be done by some sort of microservice architecture but I don’t know how these would then best talk to each other…
2
Answers
If you are lucky you can just use the .net framework libraries in .net 5+ projects directly. Some APIs have been removed between .Net 4.8 and .Net 5, and if these APIs are used you will get runtime errors, and because of this Visual studio will complain. But it should be fairly easy to test, and may work just fine.
Also note that you can code in the latest c# version in a .net framwork project by using a
<LangVersion>latest</LangVersion>tag in the project file. This will only work for "syntactic suggar" stuff that do not need runtime changes. But such syntactic suggar still helps development a fair bit.The universal solution is to run the different .net projects in different processes, and use your favorite type of Inter Process Communication (IPC) method to handle calls. There are many such methods to chose from but you could start by checking out gRPC. Do note that this approach will mean a decent amount of overhead in development, since any calls need to go trough an extra communication layer.
Process isolation
A third party DLL that uses a framework that is out-of-step with your organization’s norms should be isolated to its own process when possible. This process should run under its own application identity adhering to a standard of least privilege. This reduces the blast radius if (heaven forbid) the third party has quality issues or vulnerabilities in their software.
One approach would be for your organization to write a thin RESTful wrapper for the DLLs that runs as a web service in its own application domain. The rest of your enterprise software would merely call the RESTful interface. The DLLs need only be deployed to the single web server. From there you can apply patches and upgrades from the third party on whatever their backwater schedule may be.