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.

Caching across Applications in .Net on a Windows Machine

I am trying to implement caching in .Net such that the cached data is accessible not just by an application that may run multiple times on the same machine but by other types of applications that may run on the machine. They could be windows services, web services, win forms etc.
I have looked at System.Runtime.Caching (because Enterprise Application Blocks Caching is going to become obsolete) as a means to achieve this. The default MemoryCache is insufficient to achieve this as I don't believe that it work across app domains.
Is there a way I can implement the kind of caching I am looking for or is there a caching dll of some sort (must be free) that I can use to achieve my goal?
Is there a way to use System.Runtime.Caching with IsolatedStorage scoped to MachineLevel?
I've looked at memcache too and can't use it because we need this to run on windows machines. I started looking at SharedCache (http://www.codeproject.com/KB/web-cache/AdvanceCaching.aspx) and am curious about the pitfalls it has as well.
Thanks.
-- Revision 1 --
I think the optimal solution for me would use the Caching object to a Memory Mapped File (http://msdn.microsoft.com/en-us/library/dd997372.aspx). So the question I have now is whether anyone has done that with the System.Runtime.Caching object. There must be a way to extend it if necessary...examples of how to do so would also be much appreciated.

You're looking for AppFabric Cache. It's a Windows Server technology from Microsoft. It's free.
I should also say that if you like memcached, you can use that on Windows as well, and in fact Microsoft Azure team members used to recommend it, before the AppFabric caching was available on Windows Azure.

Have you evaluated Microsoft Velocity? Take a look - I believe if you are not okay with using the AppFabric Cache, this should work out for you:
http://msdn.microsoft.com/en-us/magazine/dd861287.aspx#id0450004
For simple client based caching, you can look at file based caching.

How to handle BL cache for multiple web applications?

I recently received a project that contains multiple web applications with no MVC structure. For starters I've created a library (DLL) that will contain the main Business Logic. The problem is with Caching - If I use the current web context cache object than I might end up with duplicate caching (as the web context will be different for every application).
I'm currently thinking about implementing a simple caching mechanism with a singleton pattern that will allow the different web sites (aka different application domains) to share their "caching wisdom".
I'd like to know what is the best way to solve this problem.
EDIT: I use only one server (with multiple applications).

Depending on the type and size of the data you want to cache, I'd suggest:
For small amounts of primitive data : nCacheD (codeplex) - memcached redux for .net
For heavyweight objects : MS Patterns and Practices Caching Block (msdn)
In general though, I would look at my requirements and make really sure an all-encompassing cache is really needed, and writing code to maintain its state (and tune its resource consumption) would not be more expensive than going straight to the database.
If most of the stuff you want to cache is static pages, or a combination of static & dynamic content, I would look into utilizing IIS/ASP.NET's page level cache.

I have two different suggestions depending on your plans to be scalable. Regardless of the back end cache you choose i would suggest that you first implement an adapter pattern layer that abstracts you from your cache, as a result it will limit your dependency on the cache and give you the ability to swap it out later.
If you want to scale out by adding a web farm (more than one application server) then look at velocity. Microsoft will be packaging this in 4.0 but it is a CPT3 currently and is very easy to use.
Documentation
Download
If you dont plan to move to a multiple server system then just use the HttpContext.Current.Cache

Sounds to me like you should take a look at Build Better Data-Driven Apps With Distributed Caching. The article describes a new, distributed cache from Microsoft (codenamed Velocity).

I've also been offered to use SharedCache, which look exactly like the architecture I'm looking for: Single Instance Caching.

How to promote WCF to a non-techie?

How would you describe and promote WCF as a technology to a non-technical client/manager/CEO/etc?
What are competing solutions or ideas that they might bring up(such as those they read about in their magazines touting new technology)?
What is WCF not good for that you've seen people try to shoehorn it into?
-Adam

Comparing with .asmx: WCF is the next generation of Microsoft's Web service development platform, which addresses many of the issues with older versions, specifically:
better interoperation, so you can interoperate with Web services that aren't from Microsoft or that are published on the Internet
much more flexible, so it's easier and faster for developers to get their jobs done
easier to configure without changing code, reducing the cost of maintenance significantly
It may be that they raise the question of how it relates to SOA, a "service-oriented architecture". WCF is the Microsoft solution for creating applications that participate in these distributed systems.

Tell them it'll let you do your job easier which translates into less time and less money.

In a single sentence, I'd say that WCF is "software that lets you set up and manage communication between systems a lot more efficiently than in the past".
I can see them bringing up BizTalk as a competitor, but of course you could say that WCF works with it and is in fact used as base technology for it in the more recent versions.
I'm not sure if I can think of any inappropriate shoe-horning of WCF that I have seen, although there are plenty of legacy apps that will probably be "upgraded" to WCF that don't really need to be for any real business reason.

There is an inter-op angle as well. If you upgrade your Asmx services to WCF services you can still honor your asmx clients and then start moving forward with newer WCF clients. WCF is starting to get some ReST attention, RSS is there, Silverlight has a place with WCF. Performance is better, depending on the bindings you choose. One of the big draw backs is a steeper learning curve comapred to Asmx services, the great power/great responsibilty problem and then the 101 ways to do the same thing.
None of this is CxO talk but refactor the language into magazine buzz words so that they can see the future of this technology.

Logic first, WCF security later?

I'm working on a WCF service that will be communicating over net.tcp to n instances of a client app (that is being developed by another programmer in my office).
At the moment I am using net.tcp without any security as I felt setting this up at this stage wasn't necessary, at least not until we are closer to rolling out.
During the development of a WCF application, is there any harm in using a standard binding (net.tcp in my case) without security, then once the business logic has been completed, implement all the security requirements? Are there any things I need to be aware of that may not function after the implementation of security?

While your overall design should consider security from the very beginning, I don't think it's a good idea to couple your components to any particular security strategy. You may very well want to use some of your components in a non-secure manner or across a different protocol which offers different security options.
So my answer is yes and no. Yes you need to think about it from the beginning, but no you should not couple your components to your security needs.
That said, since you know that you'll be using net.tcp you should be aware that transport security is turned on by default for this binding.
For tons more information, see Juval Lowy's fantastic Programming WCF Services, chapter 10. Lowy, in his ServiceModelEx library (discussed at length in the book) provides a really nice framework that you can plug in after you've created your components. Even if it's not exactly what you're looking for you can customize it to suit your needs.

Security should be thought about from the start, and not added on at the end.
Develop a plan for your security, and implement it as you go, rather then at the end.
Reference: Microsoft .NET: Architecting Applications for the Enterprise
http://www.amazon.com/Microsoft®-NET-Architecting-Applications-PRO-Developer/dp/073562609X

You have two choices, bake it in from the beginning, or slap it on at the end. With security in general I would say it really does not work in the icing so you have to make a mess of your cake to get it in there.
However, the way I see your question is you already know you need to do something to solve a security issue, you just have not decided what to do. In that case I would agree with Terry that you should then design around an abstraction that allows you to plugin the eventual solution.
If I were you I would probably do a threat model and use it to consider the inputs and risks presented by your service. This will help you decide what you should do eventually and if your abstraction covers all bases.