Graeme Hill on .NET development

Here are some tips for using SVN with a Visual Studio project:

Choosing a client

There are quite a few SVN clients out there. If you like to have one built in to the IDE, then there’s Ankh SVN and Visual SVN. I have used Ankh but found it to be a little buggy (those issues may have been resolved by now) and I have never used Visual SVN because it costs money. I prefer not to have my SVN client built into the IDE though because I often need to do SVN operations outside of Visual Studio anyways. It can also complicate the process a little bit. For example, if you just want to commit your solution file with Ankh, you would probably right click on the solution and choose commit, but this actually commits everything in the solution, not just the solution file. If you use an external client like Tortoise SVN or Rapid SVN then you will get full control over your SVN activity. Both clients are good. Tortoise is a windows explorer extension, while Rapid is a standalone app. Personally, I use Tortoise, but some people don’t like anything that messes with the explorer.

What not to commit

Most of the time you do not want to commit your binary files, just the source, so you should tell SVN to ignore the bin and obj folders in each project. Every solution also has a .suo file that stores the state of the IDE (eg: the files you have open). So for example, if user X commits his .suo file and user Y does an update, then when user Y reloads the project it will open the windows user X was viewing, not the ones user Y was viewing. This isn’t normally the desired behaviour, so you should also ignore the .suo file (it’s in the same directory as the .sln file).

External libraries

When your solution and project files are being versioned, you don’t want to have references to DLLs on your hard drive with absolute paths. Instead, it is ideal to include a folder called lib in your project and put all your DLLs in there so that the entire folder can be included in SVN, ensuring that the references will work for everyone.

Updating from an external client

If you use an external SVN client like Tortoise or Rapid then you do not need to close Visual Studio to do an update, but for the love of god, make sure to save your files before you update. If any of the files or projects you have opened are changed by the update you will be asked whether to reload them. Say yes (if you have files with unsaved changes those changes will get overwritten, that’s why you need to save before updating). This can take a few seconds if any large projects need to be reloaded. After it’s done you might see a bunch of compile errors. Usually they will disappear with a simple compile, but sometimes false errors will still be displayed until you do a full rebuild of the solution. If the compile errors persist then it is likely a legitimate error and you need to take to whoever committed last.

Omitting certain projects in a solution

If you have a project in your solution that you do not want to commit (eg: a test project) then it is not enough to simply ignore the files for that project. If you just ignore the files and commit, then when another user gets your update they will receive an error saying that the project you omitted cannot be found. This is because the .sln xml file keeps track of the projects in your solution, so now it contains a reference to a project with no files. To prevent this you need to right click on the project in Visual Studio and choose “Remove” before committing. This will just remove the project from the solution, it won’t actually delete any files. Note: removing the project changes the .sln file, but it does not automatically save those changes. In order to save the .sln file you need to recompile the solution or do a “save all” (ctrl+shift+S).

VB.NET has the sometimes useful feature of late binding, but this seems to lead to poor code. By default, late binding is enabled (ie: Option Strict is set to Off) allowing for implicit narrowing conversions (no cast). Although there are certainly cases where this is a useful feature that can cut down on the amount of reflection code left up to the programmer, I have found that it is more often a cause of less robust code and needless performance degradation.

With Option Strict Off we can write code like this:

Dim obj As Object = "Hello, World!"
Dim str As String = obj

In this case the code will run just fine, and it saved us the hassle of casting obj to String. However, we will obviously run into problems in a situation like this:

Dim obj As Object = "Hello, World!"
Dim int As Integer = obj

Even though int is an Integer this code will compile, but at runtime there will be an InvalidCastException. This is all pretty simple stuff, but the bottom line is that in this case, Option Strict Off gives a runtime error, while Option Strict On gives a compile error. The value of compile-time errors should not be taken lightly, and in my humble opinion they are a programmer’s best friend. With Option Strict On our first sample only needs a minor change:

Dim obj As Object = "Hello, World!"
Dim str As String = DirectCast(obj, String)

Was it really that difficult just to cast it? Type casting is not an inconvenience, but a necessary precaution requiring the programmer to say to the compiler: “Yes, I did intend to perform a narrowing conversion. It was not an accident”.

As a general rule of thumb, I like to set Option Strict On as the project default (go to Project -> Properties -> Compile) and then add Option Strict Off to code files that require it rather than the other way around.

I have long had an issue with Visual Studio where it takes a ridiculous amount of time to delete a file. Sometimes it takes over a minute and the IDE is completely unusable while it is loading. I finally came across a this post by Matt Hinze that gives a solution. Apparently when you delete a file it scans your recycle bin which can take a long time if there are lot of files in there. All you have to do is empty your recycle bin and you should be able to delete files with no noticeable delay.