The "best" way to communicate between .NET 1.1 and .NET 3.5

Question

For the better, I mean:

• The cheapest development cost (project 1.1 is unlikely to live> 6 months)
• Simple migration to WCF or similar

By communication between I mean:

• Remote communication between computers
• Most likely no firewall restrictions

With .Net 1.1, the following options are available: sockets, remote access, and various web service options.

An option to use binary serialized DataTables on sockets has been proposed as a solution, but I fear this.

UPDATE: The “server” in this case is Windows Embedded Standard with .Net 1.1. At this point, we cannot add any new components to the image, such as IIS, ASP or MSMQ, etc. Keep this in mind

Answer 1

Since you switch to WCF, you might want to create a WCF service right away using BasicHttpBinding, which supports older ASMX web services, i.e. WS-BasicProfile 1.1. You can easily use this service from your .NET 1.1 application.

You may also consider using MsmqIntegrationBinding in WCF, where the .NET 1.1 application will send / receive messages from MSMQ.

You can check out the following related articles:

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

Answer 2

WebServices (based on asmx) should work between the two without problems.

Answer 3

Outlets should be pretty trivial. What data do you need to send? If these are just simple strings / other primitive types, you can simply create a basic xml layout and submit it.

Answer 4

We use both remote and web services in our code for exchange 1.1 ↔ 3.5. We found that web services are easiest to port from 1.1 to 3.5.

Answer 5

In .NET 1.1, you cannot have binary-serialized DataTables. In version 1.1 and the default version 2.0 when serializing a DataSet or DataTable using a BinaryFormatter, all you get is XML serialization stored in an byte array, with bloat, which you can expect from all of these repeated tags.

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

Answer 6

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

• It provides a similar API for WCF
• This is a much higher level than sockets.
• Support for multiple "channels" (HTTP or TCP).
• It's easy enough to switch to WCF (code changes are needed).

As far as I can work, Web services are too "difficult" for 1.1 due to the fact that it requires ASP.NET, which we do not have +, as a rule, too many settings.

Sockets are too low.

MSMQ is missing only because of the high barrier to entry (similar to web services) ... we cannot add any new components to our Windows Embedded assembly (machine 1.1), and I suspect that MSMQ is not "standard".

Answer 7

You do not need to use inline serialization to serialize DataTable objects. A DataTable is just a bunch of columns and rows. You just have to iterate over the rows of the table and serialize them.

Depending on your tradeoffs, you can copy the DataTable to an equivalent data transfer object, and then binary serialize that object. Such an object will consist of an array of objects that reflect the structure of the DataTable . An object will have one property for each DataTable column.

This way you avoid serializing table metadata and you need simple and fast binary serialization.

Given this, I would avoid Remoting. It is true that the structure is somewhat similar to the WCF structure, but all of this is not supported. It’s bad that you are stuck using almost the most obsolete version of .NET, you really do not want to rely on technology, which in itself is outdated.

Sockets are not very beautiful, but they are well understood. If you are careful, you will create socket code that is relatively easy to maintain, at least as long as you have to stick with .NET 1.1.

You might want to take a look at the new classes added in .NET 2.0 ( TcpClient , for example) and create a similar API. This way, if you can ever upgrade your image to .NET 2.0, it will be easier for you to use the code that Microsoft will support.