Integrate vb6, interop, winmsg, tcp, .net2.0/3.5 together into a real life project
In a recent project, we have encountered a very complex business needs that presented a number of obstacles to our developers. Through much trial and error through, we overcame the obstacles one by one, and finally triumphed the “evil” and in the process learnt a lot of nuances of vb6 + .net.
Before I start to go into the technical details, I’ll first talk briefly the business needs the project tried to answer. Although due to confidentiality, I have to greatly simply the details, I hope my explaination will capture the big picture.
A client has an old VB6 code that does roughly 3 things:
1. Take a series of user input through a complex UI
2. Call database, do some business logic processing
3. Output the result in both text and video (windows media and flash) format to a number of screens, which may or may not be attached to the computer the VB6 program is running on.
Our job is to create a program - let’s called “Bumble Bee” because how busy it is - will run on all the screens connected to the VB6 code. “Bumble Bee” will read in the input the VB6 provides and display text and play the right videos. Sounds simple enough? So we thought.
There are some requirements about this program.
A. It has to be light weight, very light. Because the screens that run this program has very little processing power.
B. It has to be very responsive. Think of first person shooter type of responsiveness. As soon as a user enters something on the VB6, “Bumble Bee” needs to act and display. If a user continuously hits the UI input on the VB6 code, Bumble Bee needs to get real busy and flash through tons of messages and decide what video to play.
C. Bumble Bee exists in both .net 2.0 and .net 3.5 world due to legacy reasons. On .net 2.0, the client wants a winform to display text and videos. On .net3.5, they want a WPF so that it can deal with screen rotation, but as we know, WPF cannot be run on .net2.0. So suddenly, Bumble Bee needs to have two different versions, is this acceptable?
Due to the technical requirement and the business needs, we have decided to implement the following:
1. Created an interop to facilitate communicate between VB6 and Bumble Bee
2. Use WinMsg to communicate between interop and Winform for .net2.0 – this is to ensure that if Bumble Bee exists on the same machien as the VB6 program, the two programs will be the minimum lag.
3. Interop call C# WinForm by TCP Server – if the Bumble Bee program does not co-locate on the VB6 program’s machine, we need to use TCP Server/Listener technology to do it.
4. Winform dynamically load WPF – most of the funcationlity will be implemented on the Winform which runs on the required .net2.0. For the 3.5 funcationlity that requires WPF, we will simply call WPF through Winform when we can dynamically determine if .net 3.5 exists or not on the particular machine.
5. To ensure step 4, we have to make sure tha the project can install dynamically on 2.0 or 3.5.
This is the summary of what what we decided to do. In the following days, I’ll continue the blog and fill the details of the trial and error we had to walk through to get the project completed. Stay tuned…