Do you check in bin or debug folders (and dlls) into your TFS?

Question

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?

Answer 1

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.)

Answer 2

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...

Answer 3

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.

Answer 4

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

\..\..\..\NiceThing.dll

. 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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.