Some free tools to help you develop better .NET Solutions!

1. DebugView: DebugView is a free tool that lets you view the debug output written by applications on the windows operating system. You might be aware that many Try/Catch blocks in .NET applications use the Debug.WriteLine statement to make note that an error or exception occurred. DebugView displays an output log of all such diagnostics written by your application thus making the task of tracking errors much easier. In fact, on live or production systems, it is not always possible to run your application in debug mode. In such cases, DebugView comes very handy as it lets you see the exceptions written by your .NET application without disrupting any user activity.

2. FxCop: For those who wish to follow the industry best-practices while coding .NET applications, this free tool from Microsoft is a great boon. FxCop helps you with code-review by analyzing your .NET assembly and highlighting several programming and design issues such as:

  • Not following proper naming-conventions for constants and variables.
  • Improper commenting of code.
  • Inappropriate use of public variables.
  • Using obsolete or irregular keywords like goto.
  • Performance issues (use of excessive locals, declaring unused parameters, etc.)
  • Security issues (not specifying marshalling for pinvoke string arguments, etc.)
  • Design issues (Not strong-naming an assembly, hiding base-class methods, etc.)

To see a complete list of FxCop rules with an in-depth discussion and example, see msdn:

3. StyleCop: StyleCop is another opensource tool for static code analysis. It analyzes the C# source-code unlike FxCop which analyzes the assembly. It thus applies a different set of rules from FxCop. These rules fall in seven basic categories:

  • Documentation
  • Layout
  • Maintainability
  • Naming
  • Ordering
  • Readability
  • Spacing

4. CLR Profiler:CLR Profiler is an excellent tool to help you identify performance issues in your .NET application. Many a times it so happens that you notice your application is performing poorly or consuming a lot of memory, but could not put your finger on the exact function or class in code that is causing this. This tool does exactly that! It creates a call graph analysis when your .NET application is run, along with the behaviour of the Grabage-Collector. CLR Profiler is a free download from Microsoft:

Download CLR-Profiler from Microsoft

5. NANT: NANT is a free and opensource tool for automating the software build process.  NANT is specifically targetted at building .NET solutions. It automatically fetches the dependency tree and builds them in order for your .NET solution. NANT is free software:

6. Subversion/TortoiseSVN: Subversion is an excellent opensource collaboration software used by several large firms to manage inhouse development in large teams. Subversion is the server component that provides a central repository to store your .NET code, while there are several Subversion clients (TortoiseSVN being the most popular) that integrate with your windows-shell and provide SCM features and tools to:

  • Check-out, browsing and check-in of code in the SVN repository.
  • View change log and changes made by other users to the repository.
  • Compare or merge your local code with the base version in repository.
  • Resolve conflicts (if any) with the base version by gradually accepting/rejecting the changes.

Both Subversion and TortoiseSVN are 100% free and opensource:

7. Redgate Reflector: Not many people know that the EXE or DLL compiled from your Visual-Studio IDE is prone to reverse-engineering if you ship them as it is. That is because, a .NET assembly (EXE/DLL) is not directly compiled to the low-level machine code, but rather, into CIL (Common Intermediary Language) to achieve architecture independence and reduce compile time. One such industry-standard tool to reverse engineer a .NET assembly is the Redgate Reflector. Reflector takes the .NET assembly as input and regenerates the entire source-code and solution in the language of your choice (VB/C#/F#/etc). Though Reflector is a commercial product, you can use the free demo version to decompile .NET assemblies (but with some limitations):

8. AnkhSVN/SharpSVN: AnkhSVN is yet another opensource tool which is managed by Collabnet, the creators of  SVN Server itself. It seamlessly fits into the Visual Studio IDE and allows you to check-out and commit code to your SVN repositories. Also, the api used by SVN called SharpSVN is also an opensource .NET 2.0 library. You can add its reference to your .NET project if you need to automate code check-outs and commits from your application itself:

9. Windows SDK Tools: You can find a bunch of usefull stuff already installed in your Windows SDK directory itself! These are typically installed in the below folder:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\

sn.exe is the strong-name utility that you can use to strong-name your .NET assemblies.

gacutil.exe is used to install/uninstall an assembly from the .NET GAC (Global Assembly Cache).

wsdl.exe automatically generates .NET code for xml web-service clients to connect to a web-service.

svcutil.exe pregenerates C# serialization code that is required for types that can be serialized using XML Serializer.

ildasm.exe is a disassembler that generates CIL code from .NET assemblies.


How to create an FTP client in C#

Creating an FTP client in a CLR compliant languge such as C# is truly a breeze compared to native languages like C or C++. The .NET Framework class library hands you the useful classes of System.Net on a platter which you can use to write your FTP functionality without worrying about things like memory allocation, protocol handling, etc. The .NET API does that on your behalf!

Before writing the code, it is useful to sit down and give a thought to your program design. Do you want to create a library to reuse in a larger project, or just a Windows app that acts as an FTP client? If you are a student doing some test project, I bet its the latter you will prefer! However, object-oriented programming and the concept of object-reuse dictate that you create a library first and then proceed with building your GUI, though it takes a little bit of extra effort.

In this tutorial I’ll briefly explain the functionality of libftp, an FTP library I have created in C# which I can seamlessly integrate into any application I develop or distribute it as a class-library/DLL. I also built a proof-of-concept Windows Forms application along with, to ensure the new functionality is working well. The library and application are available as open-source project on codeplex. You can browse through the code, understand it and straight away plug-it in your .NET application 100% free of cost.

The workings of this library is simplicity itself. There are just two classes – ftper class that acts as an interface to this library. It exposes public methods like connect(), disconnect(), browse(), addFilesToDownloadQueue(), etc. Here are some implementation details:

public bool isProcessing()
    return _threadRunning; //check if a thread is running for up/download

public List<ftpinfo> connect(string host, string username, string password)
    return ftpobject.connect(host,username,password);

public void disconnect()
    if (_threadRunning)

    int timeout=60; //seconds
    DateTime start=DateTime.Now;
    while(queue.Count==0) //wait till running up/download threads complete.
        if (DateTime.Now.Subtract(start).Seconds>timeout)

public List<ftpinfo> browse(string path)
    return ftpobject.browse(path);

The second class, ftp is the core class which does the actual ftp stuff by connecting to the remote-host and transferring files. It is the underlying class for ftpobject in the above code.  It also exposes some events like uploadComplete and downloadComplete that our client can subscribe to, so that he/she can get notified of these events.

internal ftp() //hide constructor from the outside world.
context = SynchronizationContext.Current;

//tests connection and browse to home-directory
 public List<ftpinfo> connect(string host,string username,string password)

//FtpWebRequest.Create(host); //test connect;
 context = SynchronizationContext.Current;

return browse(host);

//public bool exists(string remotefilename)
 //    return true;

/// <summary>
 /// Fetch all files/folders in this directory and return the ftpinfo array.
 /// </summary>
 public List<ftpinfo> browse(string path) //eg: "", ""
 FtpWebRequest request=(FtpWebRequest)FtpWebRequest.Create(path);
 List<ftpinfo> files=new List<ftpinfo>();

//request.Proxy = System.Net.WebProxy.GetDefaultProxy();
 //request.Proxy.Credentials = CredentialCache.DefaultNetworkCredentials;
 request.Credentials = new NetworkCredential(_username, _password);
 Stream rs=(Stream)request.GetResponse().GetResponseStream();

OnStatusChange("CONNECTED: " + path, 0, 0);

StreamReader sr = new StreamReader(rs);
 string strList = sr.ReadToEnd();
 string[] lines=null;

if (strList.Contains("\r\n"))
 lines=strList.Split(new string[] {"\r\n"},StringSplitOptions.None);
 else if (strList.Contains("\n"))
 lines=strList.Split(new string[] {"\n"},StringSplitOptions.None);

//now decode this string array

if (lines==null || lines.Length == 0)
 return null;

foreach(string line in lines)
 if (line.Length==0)
 //parse line
 Match m= GetMatchingRegex(line);
 if (m==null) {
 throw new ApplicationException("Unable to parse line: " + line);

ftpinfo item=new ftpinfo();
 item.filename = m.Groups["name"].Value.Trim('\r');
 item.path = path;
 item.size = Convert.ToInt64(m.Groups["size"].Value);
 item.permission = m.Groups["permission"].Value;
 string _dir = m.Groups["dir"].Value;
 if(_dir.Length>0  && _dir != "-")
 item.fileType =;
 item.fileType = directoryEntryTypes.file;

 item.fileDateTime = DateTime.Parse(m.Groups["timestamp"].Value);
 item.fileDateTime = DateTime.MinValue; //null;


return files;

The reason I’ve kept the constructor method ftp() internal is that we don’t want our client creating these objects as they form the core ftp functionality that only our library is supposed to use. By using the keyword “internal”, C# compiler understands that we don’t want this consturctor to be visible outside our assembly.