We Keep Coding

What are the benefits of migrating our application over to WCF as opposed to continuing to use .NET Remoting?

Alright, so I've asked several questions on StackOverflow about .NET Remoting, and there is always at least one person who just has to chime in, ".NET Remoting is deprecated, use WCF instead." I understand that it's deprecated and there is no guarantee of future support with new versions of the .NET Framework. But what are some other good reasons we would want to move over to WCF? I have seen a few mostly minor annoyances with .NET Remoting, however, this is not enough to change the minds the powers that be who believe firmly in "if it ain't broke, don't fix it". At this time, the only reason that attitude will change is if .NET Remoting is removed from a future version of the .NET Framework, so who knows how long that will be?
Does anybody have any insight as why exactly WCF is "better" than .NET Remoting, or why Remoting is inferior to WCF? What are the pros and cons of each technology? Are there additional things you can do with WCF and not with Remoting?
I mean, it would be great if I could convince them to let us migrate our software over to WCF just to allow a configurable TcpChannel timeout to be set on the client side (this seems to have been broken for a while, no matter what steps or troubleshooting I try), and when this happens, it makes our software look like absolute shite.
Thanks in advance for helping to shed some light on this.

There are plenty of reasons to ditch remoting; a few might include:
lack of transport flexibility
versioning requirements are huge pain
platform dependent (no sensible chance of cross-platform usage)
no chance of usage from the growing mobile market
lack of future development: whatever feature you want added - it won't be
however, I would disagree that WCF is the automatic replacement; WCF itself is a pretty versatile tool, but can be pretty complex, and has restrictions of its own. I haven't used it myself, but I have seen lots of praise for Service Stack, essentially with users describing it as "WCF done right", i.e. the good bits of WCF, without the pain points. However, there are plenty of other options too. One nice thing about the idea of Service Stack, though, is that it iterates pretty quickly, and if it lacks something you want you can change it.

.NET Remoting is now a legacy technology, quoted from MSDN:
This topic is specific to 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 the Windows Communication Foundation (WCF).
And here is a performance comparison between WCF and .NET Remoting done in 2007: http://msdn.microsoft.com/en-us/library/bb310550.aspx
To summarize the results, WCF is 25%—50% faster than ASP.NET Web
Services, and approximately 25% faster than .NET Remoting.
So I guess speed is a good reason to drop .NET Remoting.

While the given reasons are probably the driving considerations there are other non-trivial reasons:
Transport independence
IDE tooling
Ease of testing
Maintainability
When you use WCF you can change transport merely by editing your config file. This can be very handy when some sanctimonious system admin won't open a port and you need to use HTTP on port 80 to get through the corporate firewall.
The WCF tooling in Visual Studio is phenomenal. The hardest part is figuring out the URL you need. After that it's just point and click for code generation. There are one or two gotchas with serialisation of collections but broadly speaking if you tell both ends to use arrays it will just plain work. If you need a collection at the destination you can always construct one around the received array, and since LINQ will happily operate on arrays you can fold this into other transformations.
I'm not sure what Stephan P means by pain points. Editing the config can be tricky but Microsoft provides an excellent GUI tool that takes all the guesswork out of it by providing a full tree of options yet generating a sparse config file.
WCF services are easy to test because they have a published interface to which you can connect a test harness. This is more a virtue of SoA in general rather than WCF in particular, but it's still desirable.
WCF makes things a great deal simpler in my code, since neither application nor service is polluted with "routing" code (to determine what ought to process the message content); it looks like simple method calls or implementations. I mostly use WCF as a wrapper for MSMQ, and the only visible consequence of the transport selection is that these method calls must all be void functions because it's a OneWay transport. But that's hardly surprising when the point was persistent queueing.
This all speaks to maintainability. Even for in-house applications, maintenance is a dominant cost, and when you're supporting your software at customer sites poor maintainability can be crippling.
Then there's interoperability with otherwise incompatible platforms. In this case I'm thinking of using HTTP/XML or HTTP/JSON to provide service to web apps written in (eg) PHP.
Going the other way isn't quite so easy but it's fairly straightforward.

I give points for WCF with respect to logging and security.
Logging
WCF has an integrated Logging mechanism that helps you log traces that become a boon during maintanence. In other technologies, developer has to do some work to achieve this but in WCF, all that we have to do is to enable trace by changing the config file and WCF starts providing traces for you.
Security
Security mechanism in WCF is fairly simple and out of box when you look from the implementors perspective but is very robust and highly secure. The best part is that for the highy used and recommended bindings, WCF provides default security which can be trusted to the core. The message security on WSHTTPbinding is an example on these lines.
.NET Framework remoting does not do authentication or encryption by default. Therefore, it is recommended that you take all necessary steps to make certain of the identity of clients or servers before interacting with them remotely
Moreover WCF is an framework to develop Service Oriented applications under microsoft platform mixing both message and rpc style of programming. Which was not in the remoting. Remoting is basically oriented to rpc only.

Non-enterprise uses for WCF?

I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?

I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.

A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data

WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.

Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.

WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.

I can't create a clear picture, why and when to use RESTful services? [duplicate]

This question already has answers here:
Why do we need RESTful Web Services?
(8 answers)
Closed 9 years ago.
Why and when to use RESTful services?
I know how to create a WCF webservice. But I am not able to comprehend when to use a SOAP based service and when to use a RESTful service. I read many articles on SOAP vs REST, but still, I don't have a clear picture of why and when to use RESTful services.
What are some concrete points in order to easily decide between these services?

This is a worthy question, and one for which a short answer does no justice. Forgetting about the fact that most people may be more familiar with SOAP than REST, I think there are a few key points in this:
First and foremost, I would suggest using REST wherever it fits naturally. If your main use scenarios involve reading and updating data atoms ("resources"), REST provides a more lightweight, discoverable and straightforward approach to data access. Also, building really thin clients (mobile devices, JavaScript, even shell scripts) is often easier with REST.
For example: If your data model is all about customers and your main operations involve reading the customers and writing back changes, REST will do just fine. Using GET/POST/PUT/DELETE HTTP protocols is an excellent way to make the protocol very discoverable and easy to use, even for somebody not intimately familiar with your application.
This, however, brings us to the second point.
What if you need to offer a web API with querying capabilities? For example, a typical scenario might be "Get me the 5 newest customers". In this scenario, pure REST provides little in terms of API discoverability. Enter OData (www.odata.org), and you're rolling again; from this viewpoint, OData URI based query syntax adds a touch of well-known abstraction above the normal extremely simplistic, ID-based addressing of REST services.
But then, there are aspects which can be reasonably hard to represent in terms of REST. Point three: If you can't model it reasonably cleanly, consider SOA.
For example, if a common usage scenario involves transitioning customers between workflow stages (say, "new customer", "credit request received", "credit approved"), modeling such stages with REST may prove complex. Should different stages be represented just as an attribute value in an entity? Or perhaps, should the different stages be modeled as containers wherein the customers lie? If it's an attribute, do you always want to do a full PUT when updating it? Should you perhaps use a custom HTTP verb ("APPROVE http://mysite/customers/contoso HTTP/1.0")?
These are valid questions to which there are no universal answers. Everything can be modeled in REST, but at some point the abstraction breaks down so much that much of REST's human-facing benefits (discoverability, ease of understanding) are lost. Of course, technical benefits (like all the HTTP-level goodness) can still be reaped, but in most realities they're not really the critical argument anyway.
Fourth and finally, there are things which the SOA model simply does great. Perhaps the most important of these is transactions. While it's a pretty complex generic problem in the WS-* world as well, generic transactions are rarely needed and can often be replaced with reasonably simple, atomic operations.
For example, consider a scenario where you want to create an operation that allows the merging of two customers and all their purchases under one account. Of course, all this needs to happen or not happen; a typical transaction scenario. Modeling this in REST requires a nontrivial amount of effort. For a specialized scenario such as this, the easy SOA approach would be to create one operation (MergeCustomers) which implements the transaction internally.
For more advanced scenarios, the WS-* stack provides facilities not readily available in the REST world (including WS-Transaction, WS-Security and whatnot). While most APIs need none of this (or are better off implementing them in a more simple way), I don't think it's worth the effort to rewrite all that just to be 100% REST.
Look into the best of both worlds. For the vast majority of scenarios, it is completely acceptable to have the basic CRUD in REST and provide a few specialized operations in SOA.
Also, these APIs can be designed to act together. For example, what should a SOA-based MergeCustomers operation return? It might return a serialized copy of the merged customer, but in most cases I would opt for returning a URI of the REST resource that is the newly merged customer. This way, you would always have a single representation of the customer even if SOA were necessary for specialized scenarios.
The previous approach has the drawback that it requires client support for both REST and SOA. However, this is rarely a real problem (apart from the purely architectural perspective). The simplest clients usually have REST capabilities by the very definition of having an HTTP stack, and they rarely run the more complex operations.
Of course, your mileage may vary. The needs of your application (and its clients), local policies and backward compatibility requirements often seem to dominate these discusssions in forehand, so the REST vs. SOA discussion is rarely on a pure technical merit basis.

An eternal question! SOAP vs. REST....
SOAP is great because it's industrial-strength, the services are self-describing in a machine-readable and -interpretable way, e.g. your computer can read, understand a SOAP service and create a client for it. SOAP is great because it's methods and all the data it will ever pass around are described and defined in great detail. But SOAP is a bit heavy-weight - it takes a lot of infrastructure to support it. SOAP is also mostly method-oriented, e.g. you define your services by means of what methods can be executed on the service.
REST is much more light-weight - it uses only established HTTP protocol and procedures, so any device that has an HTTP stack (and what doesn't, these days) can access a REST service. No SOAP heavy-lifting needed. REST is also more resource-centric, e.g. you think about resources, collections of resources, and their properties and how to deal with those (so you're basically back to the core function of create, read, update, delete). REST doesn't currently have any machine-readable service description, so you're either left to try and see, or you need some documentation from the service provider, to know what resources you have at hand.
My personal bottom line: if you want to expose some collections of data, and reach (being able to access it from any device) and ease-of-use is more important than reliability and other enterprise-grade features, then REST is the way to go. If you need serious, business-to-business, well-defined, well-documented services that implement things like reliability, transaction support etc. - then you're definitely on the right track with SOAP.
But I really don't see a REST exclusive or SOAP kind of approach - they'll be great scenarios for both.

SOAP will give you a richer set of functionality and you can create strongly typed services, where REST is normally more lightweight and easier to get running.
Edit: If you look at the ws-* standards there is a lot of stuff http://www.soaspecs.com/ws.php. Development tools such as Visual Studio make access very easy to a lot of this though. Typically WS is used more for enterprise SOA type development while REST is used for public API's on web sites (at least thats what I think).

Android (mobile OS) do not have support for SOAP. RESTful services are a much better suit when mobile devices are the target.
I personally prefer RESTful services in most cases since they are more lightweight, easier to debug and integrate against (unless you use a code generator for SOAP).

One point that hasn't been mentioned is overhead. A recent REST project I worked on involved file transfer with items up to 2 GB allowed. If it had been implemented as a SOAP service, that'd be an automatic 30%+ increase in data due to encoding. The overhead with a REST service is all headers, the rest is straight data.

Remote monitoring design

I need to monitor several systems going thru stress testing. I want to make a client-server .NET(C#) application that will ping the systems to check temperature, memory usage etc.
The client will provide system info (cpu-mem-hdd configuration) at start then it will undergo through several benchmark/stress tests. The server will keep track of what is been executed and also will be able to detect system crashes. I pretty much have all the code for the client (have been running on the system, using WMI)
I have no experience with .NET remoting nor WCF, but I think this is a great opportunity to learn them.
What technology would you use?

WCF is meant to unify .net remoting with a handful of other Microsoft technologies. WCF gives you a lot of flexibility to change the design of your client-server architecture simply by changing a few .net attributes.
I recommend you proceed with caution and make sure you have a good WCF reference at hand. You will spend a lot of time spinning your wheels in the mud without one.

Snmp, maybe based on http://www.snmpsharpnet.com/.
Nothing fancy, new and shiny, but a protocol that is meant to be used for exactly the stuff you describe. Would definitely be my first choice.
If that is not an option for you: Second choice for me would be WCF, because that can be used from different platforms (you are more flexible in the future).

i will choose service bus.

What am I missing about WCF?

I've been developing in MS technologies for longer than I care to remember at this stage. When .NET arrived on the scene I thought they hit the nail on the head and with each iteration and version I thought their technologies were getting stronger and stronger and looked forward to each release.
However, having had to work with WCF for the last year I must say I found the technology very difficult to work with and understand. Initially it's quite appealing but when you start getting into the guts of it, configuration is a nightmare, having to override behaviours for message sizes, number of objects contained in a messages, the complexity of the security model, disposing of proxies when faulted and finally moving back to defining interfaces in code rather than in XML.
It just does not work out of the box and I think it should. We found all of the above issues while either testing ourselves or else when our products were out on site.
I do understand the rationale behind it all, but surely they could have come up with simpler implementation mechanism.
I suppose what I'm asking is,
Am I looking at WCF the wrong way?
What strengths does it have over the
alternatives?
Under what circumstances should I
choose to use WCF?
OK Folks, Sorry about the delay in responding, work does have a nasty habit of get in the way sometimes :)
Some clarifications
My main paint point with WCF I suppose falls down into the following areas
While it does work out of the box, your left with some major surprises under the hood. As pointed out above basic things are restricted until they are overridden
Size of string than can be passed can't be over 8K
Number of objects that can be passed in a single message is restricted
Proxies not automatically recovering from failures
The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembly, but it's full of rubbish and certain code generators choke on it.
I know the world moves on, I've moved on a number of times over the last (ahem 22 years I've been developing) and am actively using WCF, so don't get me wrong, I do understand what it's for and where it's heading.
I just think there should be simpler configuration/deployment options available, easier set-up and better management for configuration (SQL config provider maybe, rather than just the web.config/app.config files).

I use WCF all the time now and I share your pain. It seems like it was grossly over-engineered, but we are going to be stuck with it for a long, long time so I'm trying to learn it.
One thing I am certain about, XML sucks. I've had nothing but problems using XML to control it and have since switched to handling everything via code.

The concerns you listed were:
Size of string than can be passed can't be over 8K
Number of objects that can be passed in a single message is restricted
Proxies not automatically recovering from failures
The amount of configuration while it's there is a good thing, but understanding it all and what to use what and under which circumstances can be difficult to understand. Especially when deploying software on site with different security requirements etc. When talking about configuration, we've had to hide lots of ours in a back-end database because security and network people on-site were trying to change things in configuration files without understanding it.
Keeping the configuration of the interfaces in code rather than moving to explicitly defined interfaces in XML, which can be published and consumed by almost anything. I know we can export the XML from the assembly, but it's full of rubbish and certain code generators choke on it.
here's my take:
(1) addressed a valid concern that customers had with ASMX. It was too wide-open, with no way to easily control it. The 8k limit is easily lifted if you know where to look. I guess you can count that as a surprise, but it's more of a one-time thing. Once you know about it, you can lift it and be done with it forever, if you choose.
(2) is also configurable.
(3) is known, but there are boilerplate ways to work around this. The StockTrader code for example, demonstrates a proven pattern. You can re-use the code in your own app. Not sure if this is fixed in WCF for .NET 4.0. I know it was an open request.
(4) The config is a beast. This is a concern for a lot of people. The problem here is that WCF is so flexible, and config of all of that flexibility is exposed through xml files. It can be overwhelming. An approach that seems to work is to take it in small bites, as you need it.
(5) I don't understand.

I vastly prefer ASP.NET MVC and Web API over WCF. If I had to summarize WCF to a developer who was just being introduced to it, I would say, "WCF is a well-meaning attempt to replace over-engineered, Java EE style RPC development." Unfortunately, many of the decisions made require you to become an expert in configuring low level, unimportant items (message sizes, timeouts, uninteresting protocol elements, etc.) while abstracting absolutely critical pieces (URL design, parameter serialization, response serialization, etc.). The difference in productivity and aggravation between teams I know using WCF vs. Web API is night and day.
To come clean a little: I have always hated the core concept of .NET Remoting. I feel that developers need a thorough understanding of the resource structure of their application and how these resources are serialized. Furthermore, the use of the "POST" verb for simple data retrieval is worrisome in a read heavy application that needs to scale.

I'll address the rest of your issues after clarification. In the meantime, I can address your question on when you should choose to use WCF: always.
WCF is the replacement for the old ASMX technologies, including WSE. It is also the replacement for .NET Remoting. It is the only technology upon which high-level communications features in .NET will be based for the forseeable future.
For example, consider Windows Azure. It was not inevitable that the new concept of "cloud computing" would have its communications aspects covered by WCF. Yet, WCF was flexible enough to be extended to cover those cases, with very little change in code.
If you're having trouble with WCF, then you'd do well to make sure Microsoft knows about it. WCF is the present and future of web service and other service-oriented development in .NET, so they've got a very strong incentive to listen to you and resolve your pain points. Either contact them directly through Connect, or ask questions here on SO (tag with WCF, please), and a lot of people will help you.

Biggest advantage of using WCF from a programmer's point of view: separates the definition of exposed services (operations, contracts, etc.) from the protocol's specific details, unlike ASMX where you expose a class as a web service directly in the code using attributes. Using a real example of mine: we where able to easily switch the transport protocol between web services and named pipes, whatever suited better the deployment and performance needs, without changing a line of code.

WCF is intended to SOA methodologies. Work professionally using it is a nightmare. I delivered a SOA solution using WCF as tool and hell, hundreds configurations and hidden tips! My past distributed solution using old style Web Services and Remoting were more stable. I've spent days working out the solution for the error "The underlying connection was closed: An unexpected error occurred" which makes no sense to happen for one method among 4 in the same contract. I'm very disappointed. It took me back through time where .net was first introduced with lots of promises and when we got hands on, hell, log problems came up!

To address the problem of maintenance nightmare of application config, some standard like UDDI or WS-Discovery exist, WS-Discovery will be supported by WCF in .NET 4.0.
Keeping the configuration of the
interfaces in code rather than moving
to explicitly defined interfaces in
XML, which can be published and
consumed by almost anything. I know we
can export the XML from the assembley,
but it's full of rubbish and certain
code generators choke on it.
Can you be more explicit ? I think you are talking about service behavior configured in code.
You can easily code behavior extensions to configure what your are talking about in config file instead of code BUT I think that if microsoft didn't do that there is a good reason.
For example a service with this behavior :
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)]
The implementation knows that the instance is not shared between multiple thread so it's developed differently than :
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)]
In this case the service implementation should take care about concurency problems.
The implementation is coupled with the attribute ServiceBehavior, so moving this behavior in a XML file is not a good idea.
What if you can change a InstanceContextMode.PerCall service to a InstanceContextMode.Single service inside the config file ? You break the application !

Looking at how you mention XML and SQL, you are using WCF to build a web application or an actual web service (service on the Web, and not just SOAP exchange).
It helps thinking about WCF as a replacement for .NET Remoting (or DCOM, CORBA etc), which also happens to support web services as one of the transports. Interfaces declared in assemblies, behavior of proxies, certain configuration options and other aspects of the framework that look unnatural and complicated from perspective of web apps - actually do work out of the box for DCOM-style systems of distributed objects.
To answer the question: no, you are not missing anything and using WCF for web applications is complicated, because WCF is not a framework for building web applications. Probably such framework can be built on top of it, but I would hate to see WCF itself changed to move into web realm.