用.NET编写的Windows服务被VB6应用程序占用

Question

This question is a follow up on a previous asked question: link

I have to develop a Windows Service in .NET/C#. The service must be consumed by an application written in VB6. The service implements Quartz.NET to handle scheduled tasks and must implement listeners to be able to start functions that are initiated by the VB6 application.

The requirement for the VB6 team is to be able to use Winsock. Therefor I have to use sockets and listeners. The problem is that I have no experience with that, I'm more of a WCF guy.

I'm looking at the TcpListener class now to see if this will fit the requirement.

My first question: Will the VB6 team be able to consume the service if I implement the TcpListener class, keeping in mind the short comings of using VB6 (such as data structures and binary formatting)?

My second question: Let's say 3 functions must be available for the VB6 application, and 1 listener is created. What are the best practices for the implementation of this?

Once again: any advice is much appreciated!

Answer 1

Passing payloads as XML, textual Key/Value pairs, JSON, or other loose serialization formats can help future-proof your protocol. This allows you to use and even add new optional method arguments to the server end at will.

In addition to a "method" field you can have a "protocol version" field. When a breaking change is made (new required args, changes in existing arg types, etc.) you can use the version number to handle both old and new clients during a transition period - which might span years.

As far as providing message framing on top of the TCP stream goes you can use simple EOM delimiters of some sort or a message header containing a binary or text length prefix.

You might also consider Named Pipes. TransactNamedPipe() is fairly easy to call from a VB6 program. This takes care of the message-boundary issue for you - assuming you want an RPC-style protocol rather than async send/receive.

Or you might go all the way and use MSMQ. Private machine queues don't require extensive administration. But even though both VB6 and .Net have excellent MSMQ support most devs know little about it.