2

I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!

Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.

So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).

What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?

Thanks a lot!

Fabio
  • 3,020
  • 4
  • 39
  • 62

2 Answers2

2

The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:

  1. Create a .NET 4.0 class library.
  2. Add a Service Reference to your WCF service.
  3. Create classes and interfaces which can be used to call the WCF service.
  4. Expose them as COM classes and interfaces

  5. Have your .NET 1.1 code consume the COM object and make calls through it

  6. Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".

Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.

Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I've tried this approach but I was putting the .NET 4 library inside a COM+ package (situation which we tried and realized there's a bug in .NET so the objects in 4.0 aren't release by COM+, even calling Dispose), I didn't know it works without COM+. I'm going to analyse this solution deeply to confirm if it fits our scenario, although I think it will! Thanks a lot, John. – Fabio Mar 25 '11 at 16:27
  • By the way: "The real solution is to get over the problems that are forcing you to use unsupported software" -> I think I'll have to kill some people here to do this :-) As I told you, I'm not proud of using legacy technologies, but we're looking for a way to get rid of them. – Fabio Mar 25 '11 at 16:29
1

Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.

Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.

Tridus
  • 5,021
  • 1
  • 19
  • 19
  • Hi, Tridus. We need to use some features that aren't available to .NET 1.1 runtime, that's why we need this proxy. []'s – Fabio Mar 25 '11 at 16:33