2

I'm working on a project that uses .Net Remoting to communicate with a Windows Service 'back end'. I really need to use Task<T> and async features in the back-end service, so I want to target .NET 4.5

However, due to factors outside of my control, the 'front end' component must use .net 3.5, which precludes use of all the async language features.

This is a bit of a headache.

In .net Remoting, both ends of the connection must share a reference to the remoted classes, so they are generally in a shared class library and that has been my approach. I was wondering, if I build two versions of the 'shared' class library, one targeting CLR2 and the other targeting CLR4, will the remoting pattern still work? Or does the remote end have to use the exact same object?

Tim Long
  • 13,508
  • 19
  • 79
  • 147
  • Remoting is a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using WCF or ASP.NET Web API. See the note at the top of http://msdn.microsoft.com/en-us/library/vstudio/xws7132e.aspx for proof. – John Saunders Mar 19 '14 at 20:12
  • I guess that's another alternative, but you're essentially saying "I wouldn't start from here if I were you". Sometimes one has to make the best of imposed constraints. – Tim Long Mar 19 '14 at 21:34
  • If, and only if, it actually _is_ an imposed constraint. Then, keep in mind that you're using technology that's not recommended to be used. In fact, I expect there are very few developers who have ever used Remoting, and there will be fewer every year. – John Saunders Mar 19 '14 at 22:43
  • @John I may investigate switching at some point. Tell me, can a CLR4 app host a WCF service based on a CLR2 contract? – Tim Long Mar 19 '14 at 23:37
  • Do you mean, "host" or do you mean "consume", because the platform needn't matter to the consumer. A Java 7 application should have no problem consuming a WCF service (in general). If you mean hosting, then I'm not sure why you wouldn't upgrade the service contract interface, like all other code, to .NET 4.0 or 4.5/4.5.1. If for some reason you couldn't, then the question would be "can a CLR 4.0 class implement an interface from a CLR 2.0 assembly", and I don't know the answer. – John Saunders Mar 20 '14 at 01:09
  • The answer to that final part is "yes" although I agree it is kind of a redundant question. I have done a bit of reading up and it actually looks like it wouldn't be too bad a job for me to convert to WCF. I may give it a go in a minute, there is only one main class that I need to convert. – Tim Long Mar 20 '14 at 01:33
  • Great. Keep in mind, you get to use things like binary transfer over TCP/IP or named pipes. It can be about as fast as Remoting - faster in cases where you didn't really need Remoting features to begin with, only process to process RPC. – John Saunders Mar 20 '14 at 03:20

4 Answers4

3

Yes. I have done it. We had a solution based on Remoting where each of our stores had a "listener" (service that's called by the client). There's a program in the corporate office's helpdesk that was a "sender" (client). Both initially written in .NET 1.1.

Eventually, we needed to do some updates, and the "sender" was upgraded to 2.0, and it worked just fine with the "listeners".

The key thing isn't the runtime version, it's the interface that's created. We just couldn't change the signature.

David
  • 72,686
  • 18
  • 132
  • 173
  • +1 That is exactly what I needed to know. Activation seems to be based on the "Well Known Type Name" so it looked like it should work, I just wasn't sure whether the remoting engine did some magic checks on the classes. I think I am going to make a façade class that implements the same interface as the remoted class, but just has null implementations. That way I will not have to worry about making conditionals around .net-4-only code. Keep me covered, I'm going in... – Tim Long Mar 19 '14 at 20:28
  • it works! Well that was a lot less painful than I thought it would be :) – Tim Long Mar 19 '14 at 21:34
1

.net 4.0 may work in mixed mode and reference .net 2.0 assemblies so you can use the same asseembly. See: What 'additional configuration' is necessary to reference a .NET 2.0 mixed mode assembly in a .NET 4.0 project?

Community
  • 1
  • 1
Bogdan
  • 484
  • 2
  • 7
  • That is actually a very useful thing to know, but it doesn't solve my problem in this case, since the application that will consume my class library is constrained to CLR2. But +1 because I think this will help me somewhere along the line. – Tim Long Mar 19 '14 at 20:25
  • @TimLong Make your class library for 2.0 and use this to load it in 4.0. – Bogdan Mar 19 '14 at 20:29
1

What I did in the past is that I created a new project with the same source code plus some compile symbols to enable/disable features. Something like:

MySharedLibrary.csproj (4.0)

MySharedLibrary.3.5.csproj (3.5)

The remote server should not matter unless you are transferring objects that are not available or serializable in 3.5. Of course, you have to link/reference each side to the matching lib version.

Gonzalo Contento
  • 857
  • 9
  • 21
0

Shared Class Library containing Remoting Service API must be compiled with Framewoer equal or lower than Client Program. We had a Remoting Client/Server aplicacion, and Server was updated to VS2013 and recompiled Shared library with .NET 4.5.2, the Client did not connect (compiled with .NET 4.0) until Shared Class library was compiled also with .NET 4.0 Regards.

JCapi
  • 1