FTP in .Net

Doing FTP in .Net is not as hard as you may imagine. There is a very simple way and a bit advanced way. Simple way is using System.Net.WebClient class    and its UploadFile method. Advanced way includes using System.Net.FtpWebRequest and System.Net.FtpWebResponse classes. Using them you can do ordinary FTP operations like ListDirectory, UploadFile, DeleteFile, etc. For an example see following code. More information is available from here.

public void DeleteFile(string remotePath)
    FtpWebRequest request = (FtpWebRequest)WebRequest.Create(remotePath);
    request.Credentials = new NetworkCredential("user name", "password");
    request.Method = WebRequestMethods.Ftp.DeleteFile;

    FtpWebResponse response = (FtpWebResponse)request.GetResponse();


Customizing build process in TFS 2010

If you ever has need to customize build process in Team Foundation Build 2010, you may noticed that there is several ways to do it while each way is suitable for a specific range of requirements:

1. Running external tools like batch files or ftp.exe or MSBuild Community Tasks via InvokeProcess or via MSBuild Activity.

2. Invoke .Net classes and methods like System.IO.File.Delete() via InvokeMethod.

3. Creating your own custom workflow activity for TFS Build 2010.

For our specific need that is synchronizing a remote server via FTP, none of first 2 ways is suitable. In first way, running external programs, this is very hard to synchronize a whole remote directory and its sub-directories just via ftp.exe and a bunch of batch file commands like FOR. In addition, this may impose dependency to external tools in the server.

In the second way, running .Net classes and methods, we have to create our own ftp utility or use third party tools like ftp.exe or MSBuild Community Tasks. In addition this causes using intensive usage of TF Build activities that’s not easy to copy to new Team Foundation builds in new projects.

Third and last way, creating your own activity is harder to implement but has many advantages over other ways including:

1. High flexibility because this is entirely written by yourself.

2. Maintaining is easier because all of your work is kept in a single Visual Studio project.

3. It is easier to deploy it in new team builds because it is simply just one single workflow activity.

4. It is easier to configure. You configure it via its arguments and variables. No need to modify template process itself.