We recently had an old client contact us with an unusual request. We last worked with VEXIS Systems Inc. back in 2010 when we extended the telephony server we’d built for them to support CLR hosting, using The Server Framework’s CLR Hosting Option. We then built a managed plugin system that integrated with the existing unmanaged system so that they could write their business logic in either unmanaged code or in a managed language such as C#. This has all worked well for them since.
They contacted us because they had some issues. Staff turn-over and time passing had left them with a system that they couldn’t build due to lack of knowledgeable staff and the fact that the system last built with Visual Studio 2008. This hadn’t been an issue for them until very recently and the original product was still working well.
Anyway, we got back involved with the project, upgraded the system from 2008 to Visual Studio 2022 and cleaned up and scripted the build system so that they could move forward. It was a fun project. There is a lot of change between Visual Studio 2008 and Visual Studio 2022, and we moved the system forward slowly, via VS 2012, 2015, 2017, 2019 and finally to 2022. Each step required adjustments to the code due to warning changes and C++ compiler changes but doing it in small steps made these easier to manage. The resulting system builds with 2017 through 2022.
In a similar vein our secret Industrial Control Client wants us to look at a different version of one of their programs that we’ve previous worked on with them. This version builds for custom hardware using a cross-compiler in Visual C++ 6, running in an XP VM. With this project we need to have c++ code that does network message creation and deblocking and port it from the Visual Studio 2022 version of the code back to the cross-compiler version. The idea being that, in future, both versions can be more easily kept in sync when the network protocol changes. Should be fun!