I had an interesting discussion today about the differences between writing a Windows service in .NET and an ASP.NET web application. Somebody made a comment that Windows services were harder to write because you need to make sure you deal with memory properly in order to avoid memory leaks, whereas you didn't need to do this with an ASP.NET web application. In short, the perception was that Windows services are long running processes and that ASP.NET applications running under IIS aren't. There are several things to pick up on here.
First of all, .NET (like Java) is a managed platform that does its own garbage collection so you don't need to worry about explicitly allocating and disposing memory. Unless you're integrating with unmanaged code (e.g. older DLLs, COM objects, other native code, etc) you don't generally need to worry about low-level memory allocation.
Memory leaks *are* something that you need to worry about though and they're really easy to cause in .NET or Java applications. All you need to do is cache lots of data in static references, not dispose of resources you are using, etc. You're not really "leaking" memory, you're just storing it away somewhere and never reusing it again. If you're interested in this topic, InfoQ published a good article today called Dealing with Memory Leaks in .NET that digs into this some more.
The thing that I found the most surprising is the difference in how Windows services and ASP.NET applications are often viewed. A Windows service is clearly a long running process because once it's up and running, that's it until it gets restarted manually or from a system reboot. With a Windows service, any memory leak will start to become very obvious as the system slowly grinds to a halt and it's this that caused the comment about Windows services being harder to write. For some reason, ASP.NET applications aren't necessarily perceived as long running processes. With my Java background, I find this odd and several times people have mentioned that they rely on AppDomain recycling in IIS to prevent their applications from consuming too much memory. AppDomain recycling is essentially the same as what happens when you hot-deploy a web application on a Java EE server - drop the classloader and plug-in a new one to reload everything from a fresh state. For a moment then, let's think about what happens when an AppDomain behind an ASP.NET application is recycled in IIS (there's a much more detailed explanation here).
AppDomain recycling can have a fairly large overhead then, which brings me nicely onto the point of this. You're likely to have fewer issues in the future if you design every piece of software as a long running process. It doesn't matter whether you're building a Windows service, an ASP.NET web application or even a desktop application; you should always write code to avoid memory leaks rather than ignoring them. Relying on restarts or AppDomain recycling as a workaround for sloppy coding and memory leaks is not my idea of software craftsmanship.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.