.NET Remoting

[wxman]

The app uses a third party tool for remoting http://www.genuinechannels.com/

However the tool is no longer supported

"We have been using GenuineChannels in our product for the last 4 years. GenuineChannels now appears to have become unsupported and the main developer guy Dmitri has I think joined Microsoft. I have the source as part of the product but not the networking / .net knowledge to support it."

Looks like I need to go towards WCF http://msdn.microsoft.com/en-us/netf.../aa663324.aspx

Oh well hitting the ground running on this gig has ment pointing out the wrongs of the clients current app (not gone down well due to the money that has already been spent) - there are some right howlers in there - the previous (contrator?) had no concept of modular apps - he has even hard coded the DB connections strings into the app

So there are seperate apps for each of the client customers (cust base is 40) - why? the code is the same FFS.

Don't you just love inhereting a poor design.

Oh well roll on may and storm season.

[thelace]

Meh, it's all just a typhoon in a teacup

[FSM with Cheddar]

No reason to assume only permies do that. Maybe a contractor wanted to be able to talk about .net remoting for future work.

Oh yeah, wasn't saying contractors are innocent.

In my permi days, I had to support an application after a contractor had developed it. Was an absolute nightmare. Triggers and updateable views in SQL Server all over the place. It was impossible to know the consequences of changing anything in the db.

Agree with what you said about speed. I've seen some very efficient remoting apps that are very fast.

[d000hg]

Probably because the permi had just read about remoting, and thought they would try it out.

No reason to assume only permies do that. Maybe a contractor wanted to be able to talk about .net remoting for future work.

[d000hg]

Sounds like just for fun, unless the original coder thought there was potential to scale to multiple servers (unlikely from what you said), or that it might be something reusable on other projects.

Although, how slow is slow? Just how much activity are we talking here, because .net remoting should be suitable for 'proper' applications... are you sure that's the reason for slowness? If so, maybe it isn't working right...

[FSM with Cheddar]

Probably because the permi had just read about remoting, and thought they would try it out.

Definitely no technical reason to use it in this case.

[wxman]

New gig just started - all looks ok with the exisiting project apart from .NET remoting

The C# app interfaces with a few PCL controlers on a production line as well as an SQL database - what baffles me is why? the ex contrator went down the .remoting route (of which I have no knowlage).

The app is pushed client side (to the production floor) via 2003 terminal services using WYSE thin clients - thing is ... if the app is on the same box as the SQL etc - why bloat the app with remoting - why not just interface the sql directly ??

what am I missing? - the app is slow due to the the overhead of remoting instead of making direct calls to the DB.

This app is only ever LAN based within the same IP subnet.