I have two versions A and B of the WinIDEA library. and they have the same name i.e. IConnectCSLib. There are some functions in these two versions which are similar, but some functions which are different.
So far, I had implemented a static wrapper of the version A called WinIdeaWrapper to write functions, because that is all I needed to get it to do what I wanted. And implementing it as static made sense because the wrapper was supposed to be stateless, and WinIDEA always changes state without any notification to the wrapper. This wrapper was being used in different visual studio solutions to run WinIDEA and get stuff done.
Lets assume that the Visual Studio solution that was working up until now in production was called BMW.sln. In addition I have another solution called Refactor.sln which includes all the projects in my repo, which I use to refactor stuff, because there are many solutions in our repo, and refactoring in only one creates many errors in other solutions.
Now I have to support a project that only works with version B of WinIDEA. The dll provided with the version B has a 50% overlap with the version A in terms of functionality. So 50% of the functions from WinIdeaWrapper will work with version B, which other 50% will fail. So, obviously, given the project organization structure of the Visual Studio, I have to separate the dlls and their wrappers. Lets assume, all the APIs are organized for this new project in hyundai.sln
How can I implement a wrapping classes structure (preferably static (or singleton at worst)) so, that I can avoid code replication for the common functionality between version A and B. At the same time, I can have function which can be overridden from both wrappers A and B with different internal workings. which can be referenced by different solutions, but at the same time can be included in one super solution refactor.sln for easy refactoring.
So far, I have created two different VS projects called Winidea_A and Winidea_B, which will house their respective WinIdea dlls and wrappers. But, I am not sure how to link these classes to a common class so that I dont have to implement same function in two places.
My colleague suggests using two different interfaces called IWinideaGeneric, and IWinideaSpecific, and implementing them in the wrappers. I can see how that would work but I cannot imagine how the namespace, or class name conflict will work in the refactor solution.