"Best" way to communicate between .NET 1.1 and .NET 3.5

By best I mean:

• Cheapest development cost (1.1 project is unlikely to live > 6 months)
• Easiest migration to WCF or similar

By communicate between I mean:

• Remote communication between computers
• Most likely no firewall restrictions

With .Net 1.1 the options appear to be: sockets, remoting, and various flavours of web service.

The option of using bina开发者_开发问答ry serialized DataTables over sockets has been proposed as a solution but I am wary of this.

UPDATE: The "Server" in this case is Windows Embedded Standard with .Net 1.1. At this stage we are unable to add any new components to the image such as IIS, ASP, or MSMQ etc. Take that into consideration

Since eventually you will be migrating to WCF, you may want to consider building a WCF service immediately, using the BasicHttpBinding, which supports the old ASMX style web-services, i.e. WS-BasicProfile 1.1. You would be able to easily consume this service from your .NET 1.1 application.

You can also consider using the MsmqIntegrationBinding in WCF, where your .NET 1.1 application would post/receive messages from the MSMQ.

You may want to check out the following related articles:

• ASMX Client with a WCF Service
• Consume WCF BasicHttpBinding Services from ASMX Clients
• Difference between BasicHttpBinding and WsHttpBinding
• Calling WCF services from .NET 1.1
• MSMQ: Net vs Integration

WebServices (asmx based) should work between the two without a problem.

Sockets should be fairly trivial. What sort of data do you need to send? If it's just simple strings/other primitive types, you can just come up with a basic xml layout, and send that.

We use both remoting and web services in our code for communicating 1.1 <--> 3.5. We have found that web services are the easiest to port from 1.1 to 3.5.

In .NET 1.1, you can't really have binary-serialized DataTables. In 1.1, and by default in 2.0, when you serialize a DataSet or DataTable with a BinaryFormatter, all you get is XML serialization stored in a byte array, with the bloat you might expect from all those repeated tags.

In .NET 2.0 and beyond, you can set RemotingFormat = SerializationFormat.Binary on a DataSet or DataTable to get true compact binary serialization, but I don't believe that's an option in .NET 1.1.

Believe it or not, after some investigation, Remoting actually looks like a very good candidate for this:

• It gives a similar API to WCF
• It much higher level than sockets
• Support multiple "channel" (HTTP or TCP)
• Is fairly easy to migrate to WCF (code changes are needed).

As far as I can work out Web Services is "too hard" for 1.1 because of the fact it requires ASP.NET which we don't have + generally too much setup.

Sockets is too low level.

MSMQ is out just because of high barrier to entry (similar to Web Services)... we cannot add any new components to our Windows Embedded build (the 1.1 machine) and I suspect MSMQ does not come "as standard".

You don't need to use the built-in serialization to serialize the DataTable objects. A DataTable is just a bunch of columns and rows. You should simply loop over the rows of the table, and serialize each one.

Depending on your tradeoffs, you might want to copy the DataTable into an equivalent Data Transfer Object, then binary serialize that object. Such an object would consist of an array of objects which mirror the structure of the DataTable. The object would have one property for each column of the DataTable.

This way, you avoid serializing the table metadata, and you should get easy and fast binary serialization.

Given this, I would avoid Remoting. It's true that the structure is somewhat similar to that of WCF, but it's all but unsupported. Bad enough you're stuck using almost the most obsolete version of .NET, you really don't want to rely on a technology which is, itself, obsolete.

Sockets aren't pretty, but they are well-understood. If you're careful, you'll create socket code that is relatively easy to maintain, at least for as long as you must stick with .NET 1.1.

You might want to look at the new classes added in .NET 2.0 (TcpClient, for instance), and create a similar API. That way, if you're ever able to update the image to .NET 2.0, then you'll find it easier to take advantage of code that Microsoft will have to maintain.