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

Question

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 binary 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

Eucken

Remoting is present in 1.1 ... if WCF is based around similar concepts would that not given a smooth upgrade path? – Eucken

I'd be careful about thinking that the 1.1 project would go away so soon. Sometimes one thinks something will be gone in 6 months and then 8 years later thinks, "Wow, we're still using that?" as I can look at the Windows 2000 servers we still use where I work even in 2010. – Cortneycorty

JB, i follow you. in this case the cycle times through releases is pretty steady... we only support 2 releases at once (old + current), the 1.1 has already been in the field a while so next major release will force into into the deprecated queue! – Eucken

Answer 1

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

Som

The "server" in this instance is the 1.1 application. Will this work in reverse? Consume the 1.1 web service from WCF? – Eucken

Yes a WCF client using BasicHttpBinding can consume ASMX web-services. Even the MSMQ method with the client using MsmqIntegrationBinding remains an option. – Som

I wish people would stop voting for this ;) As best I can work out we are unable to use Web Services at this stage because of the IIS dependency – Eucken

I believe remoting is a .NET-specific technology, limiting it's flexibility with other clients. As long as you are using .NET for both the client and server, then you'll be fine. WCF should be able to handle connections to servers using .NET remoting, but I'm not sure how easy it is. – Crumpled

We used BasicHttpBinding in the end – Eucken

Answer 2

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

Ranged

Is it possible to host an ASMX inside a regular process (not ASP.NET)? – Eucken

No. That is not practical. Why would you need to do this? – Pasteboard

because the server is actually an embedded device running a service which is not ASP.NET – Eucken

Is it possible for the embedded device to consume a webservice? this way it could periodically call the webservice initiating the communication itself rather than something connecting to it? – Ranged

Potentially, but its the embedded device which holds the data we are trying to remotely edit. I am not convinced server initiated communication will be workable – Eucken

Answer 3

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.

Bilbrey

The app is essentially a remote data editor, so think relational data or business objects (TBD) – Eucken

Hmm, still, if the data is simple enough it should still work. I might investigate Mark's option first though, assuming you can make the ASMX's connect and send actual objects, life might be much better. – Bilbrey

Answer 4

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.

Reciprocate

How similar are the WS interfaces that 1.1 can produce to what you will get with WCF? (my 1.1 is a bit rusty!) i.e if the 1.1 app was eventually replaced with 3.5 would be good if the client transition was fairly seemless. 1.1 does not support generics for example.. – Eucken

It looks like you can create a 1.1 Compatible WS with WCF, that maybe the way to go, until you can get all your clients to upgrade. – Reciprocate

Is the porting cost for either of them significant? – Eucken

Not really there were just the normal costs associated with moving 1.1 to 3.5. – Reciprocate

Answer 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.

Decentralize

very interesting. gives me some ammunition to shoot down the sockets + binary datasets. thanks – Eucken

Answer 6

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".

Eucken

Have you considered writing up a REST-style WCF service? Writing one in .NET 3.5 is ridiculously easy, and consuming the service is just as easy. This is a great tutorial for building and consuming REST services: robbagby.com/rest/rest-in-wcf-blog-series-index Doing that removes the need of setting up ASP.NET on IIS to host your .NET 3.5 app. WCF can be hosted easily in any kind of application, such as a windows service or console app or WinForms app even. – Crumpled

problem is the server is .net 1.1 ... with no IIS available. We need to be self hosted (like 3.5), not sure it can be on 1.1. Also no WCF on 1.1 would need to use 3rd party, or roll own REST... then starts sounding like too much work – Eucken

Answer 7

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.

Pasteboard

some interesting thoughts. but the support status of Remoting does not concern me so far... yes its legacy but its still supported and used widely by .net itself. Would rather that than trust home grown socket code – Eucken