Quick question about TFS - Do you guys check-in bin/debug folders into TFS? (if so, why?) Since the content of those folders are dynamically generated is it better to leave them out so that the programmer will not run into read-only issues?


9 Answers 9


As a general rule, source control is best used for source only, and generated files are not source.

There are exceptions. Sometimes (using Visual Studio) you might want to keep the .pdb file for reading minidumps. Sometimes you can't duplicate a toolchain, so that you can't necessarily recreate generated files accurately. In these cases, you're primarily interested in doing this for released software, not for every VCS change, and in any case these can easily reside in versioned folders. (These are typically binary files, anyway, and don't have comprehensible changes from one version to another, and don't benefit all that much from being in a VCS.)

  • 6
    If you're interested in keeping debug symbols, you're better off setting up a symbol server. If you do it right (with source indexing), debugging a minidump will first pull the symbols from your symbol server and then the relevant source from your source control... If you just check in and tag each build, you'll have to do this manually.
    – Shog9
    Dec 22, 2010 at 20:47

Simple answer? No. Don't do it! I can't think of many reasons not to, but no reason why you would want to.

The only time I can think you would check in a dll is if it's from a third party library that you don't expect every developer to have installed to build. But even still, that's not located in the bin folder.

That being said I did work at one company that required that each deploy package be put into source control, but that was so that we could track the various builds we gave to our client and could easily roll back if we had to.

  • 1
    Prime reason not to: How many terabytes of storage do you want your source control to consume?
    – EKW
    Oct 10, 2015 at 5:44
  • 1
    @EKW C# for example historically does not produce identical binaries from the same source. That may be different now with .NET Core but this was one reason to keep generated binaries for released builds for example. I wouldn't put them in source control though. It's not the right tool for that job.
    – Shiv
    May 30, 2017 at 0:34

We do not check in the bin folder into TFS. As you have probably noticed, if you do that, every time any developer builds the solution, they will be checking out the bin folder. Not good. However there are libraries that the project needs in order to compile and run, and our rule is that any project should be able to be opened from source control, and it should compile and run. So what we do is create a "BinRef" folder for any DLLs that the project must have reference to, and create the Project References to the copy in the BinRef folder. The BinRef folder is checked in to TFS.

The other advantage to this approach is that BinRef is always at the root level of the web project. If my project lives in C:\Projects\Marcie\SomeProjectCategory\ProjectA and I create a reference to a DLL that sits in C:\DLLsThatILike, the reference will end up looking something like


. You may keep your project files in C:\ProjectA which means that the project reference to NiceThing will blow up on your machine. Hopefully people aren't doing references this way, but I've seen it happen.


We check-in the contents of the bin directories as part of our Change Request process. To avoid the read-only issues, we copy the contents to a separate folder and check them in from there. Our corporate policy requires that all binaries that go to production are checked-in separately from the source. It's not the best solution but it works and it does give us the exact files that are in production.

  • 2
    At first I was going to pass by this answer, then I thought about it a bit more. In my company we don't really have a Disaster Recover plan (too long to go into). This might be useful in the case of having to start from scratch. I could just pull the binaries out of source control, throw them on the server and be done.
    – user7676
    Dec 22, 2010 at 23:48
  • @user7676 - you could just recompile the code at the version number that's in production. But admititally if you have no DR plan and you're in some sort of diaster it would be easier and faster your way. PS. YOU NEED A DR PLAN!!!
    – Ali
    Dec 22, 2010 at 23:56

I hesitate to check any non-text file into source control. Especially ones that should be generated by the developer. I also like to keep other binary files, such as images and PDFs, zipped up and stored elsewhere for each tag/release.


No, but our in house project control tool does automatically, which annoys the heck out of me.

My solution is to mark all the files in release and debug as writable and when TFS complains I tell it to ignore the files, so I never have a problem with a build failing.


I avoid entering them into source control. They're redundant information, the binaries can be built by the source code in that revision. Additionally, the source code is always up to date, the builds may not be on commit.


I save some generated binary files, like .NET interops from another project. So if I have a project A which creates a COM object, and then you use that COM object in a very loosely related project B which uses it via .NET interop, I check in that interop generated from project A into project B. It is not a good idea, but it has to go somewhere because AFAIK Visual Studio won't create the interop for your automatically during the build.


In my opinion, not storing binaries in source control is one of the most common mistakes. They should be stored, versioned, baselined/labeled together with the sources and also build tools. Suite yourself with building not traceable software...

  • 5
    You've stated your opinion but haven't given us any reason as to why it is a good practice. Someone interested in this subject will get little value from this answer without more backing it up.
    – Walter
    Oct 20, 2012 at 16:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.