Source Control and the \bin folder

The Issue

All developers that create ASP.NET web applications and use Team Foundation Source Control (or the latest version of Visual SourceSafe), have come across the situation, where after the first local build, the \bin folder is created and all dependencies and binary files are added to this folder. The issues start when the Microsoft Source Code Control Interface (MSSCCI) adds both the \bin folder and the files in the folder to the source control system. This is not that bad until someone else gets the latest version of the source from TFS and tries to build the web app. What happens is that since the files in the \bin folder (including the web app assembly and symbol files, if developers are compiling a debug version) are under source control they are read-only on disk, so the developer can't build the solution.

I've observed several different behaviors regarding this particular issue.

The first reaction is usually: "Why does Visual Studio add this folder to Source Control? This doesn't make sense!"

Afterwards, the usual course of action is to delete the \bin folder from Source Control and the local file system and rebuild the solution. Of course the feeling of success is not long-lived, because the recently compiled files are again tentatively added to source control. This is where developers usually start deselecting these files from the pending changes window when checking-in.

Another behavior I've observed, is developers allowing these files to be added to source control, but since TFS Source Control is configured to allow multiple check-outs by default, all developers usually check-out the files under the \bin folder (which marks all files as writeable in the local file system). This allows developers to compile the solution and the issue quickly slips to oblivion.

The Behavior Explained

So, before presenting what I believe is a better solution, let me just say that this behavior of Visual Studio/Team Foundation Source Control/Visual SourceSafe is in line with Software Configuration Management (SCM) best practices.

In fact, the logic behind Visual Studio adding the \bin folder to Source Control is that, at some point in time, it has to be possible to retrieve a working, coherent previous version of the solution from source control and this includes the versions of all dependencies that were used to compile the solution at that moment in time (not the latest version of the dependencies).

A Recommend Approach

So, when working with Team Foundation Source Control, every developer should add an entry to the source control folder path where the \bin folder is located and select the configuration as "cloaked" (Visual SourceSafe also has this concept). This tells the MSSCCI interface that when a get latest version action is triggered, this folder is to be ignored. What happens next is that when the developer builds the solution locally, the \bin folder in the local filesystem is updated but the files are not under source control and therefore are not marked to be checked-in.

However, to make sure that the SCM best practice is upheld, one machine has to be able to compile the solution and add the compiled files under the \bin folder to source control. This machine should be the build server.