FtpWebRequest is Broken

I’m going to take a brief break from helpful solutions to have a bit of a rant about FTP support in the .NET Framework.

When all you have is hammers..

FTP as a protocol is pretty lousy, but its support in .NET (see System.Net.FtpWebRequest) is especially terrible. If you can use an alternative, I suggest you do.

Here’s just a small list of alternatives (evaluate each based on community feedback, release/update activity, user support, and your own testing):

Why not just use FtpWebRequest?

Why not System.Net.FtpWebRequest you say?

I’ve talked before about a small framework issue when using FtpWebRequest (and have others still to post) but I’ll let that one slide in my criticism here (it’s probably System.Net.NetworkCredential‘s fault that another framework class called its internal methods).

So let’s focus on a few of my other criticisms (most of which apply equally to both FtpWebRequest and HttpWebRequest):

I’ve personally dealt with these “underlying connection was closed” issues in rare circumstances where a connection is lost and therefore “breaks” protocol without properly closing the connection, which:

  1. Leads to a series of connections stuck in TIME_WAIT just in case there’s more traffic to come.
  2. Which leads to an exhaustion of the ServicePointManager connection pool count
  3. Which means all new connections encounter the “underlying connection was closed” issue
  4. Which, requires a restart of the AppDomain (i.e. your application)

Usually someone will suggest the largely hit-and-miss idea of changing KeepAlive to false (or true if you’ve already tried that). The more effective but hacky solution seems to be trying to subvert .NET connection handling and leveraging reflection hacks.

Should a mature framework really have such a leaky abstraction?

It can’t be that bad?

The sheer fact that there are so many successful commercial libraries for something as seemingly fundamental as FTP connectivity confirms to me that the standard libraries are simply inadequate.

The cherry on top of this rather unappetising cake is that Microsoft is not only well-aware of the library’s inadequacies, but has given up on its own FTP library:

Hopefully we can see Microsoft either buy (and integrate, particularly as many of the commercial libraries are fairly low-level) or build an adequate FTP library in a future version of the framework. I’m not holding my breath.

  • http://twitter.com/wfm Bill Murphy

    Thanks for the post. I was looking at the documentation of FtpWebRequest and thinking there must be an easier way to do it!

    • http://mattmitchell.com.au/ Matt Mitchell

      Glad my rant was helpful. Alex FTPS Client seems to be the open source leader, Starksoft’s looks pretty good and was reliable in a limited usage scenario, and Rebex seems to be the commercial leader. I’ve managed to use the standard .NET libraries but they can take some wrangling and work depending on your scenario. Any interesting use case for you?