Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
You might be interested in this stack-exchange proposal. It's almost ready to begin beta, just needs a few more. –  greatwolf Jan 19 '11 at 6:16
add comment

9 Answers

up vote 19 down vote accepted

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

share|improve this answer
5  
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 '10 at 20:47
    
@Mr. CRT: Thanks. I'll have to look into that. –  David Thornley Dec 22 '10 at 20:52
add comment

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

share|improve this answer
1  
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 '12 at 16:18
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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 '10 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 '10 at 23:56
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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