Shouldn't you treat the bin folder as being transient?

Question

I've always taught myself and others to think of the bin folder as being transient.

That is you should be able to delete it and next time you rebuild it gets recreated and any references get copied into it without any hassle And not to put your eggs all in one basket. Or in this case don't put all your required dlls directly into the bin folder. Have them elsewhere and just reference them.

I've seen people falling down when they put dlls directly into the bin folder and reference them there. So I try to avoid this and put all my required dlls in a folder called Refs and add references to the dlls in there. At compile time they will get copied into the bin folder anyway.

Am I insane? Is this being too careful? common sense?

What is best practice in this scenario?

Cheers,

-- Lee

UPDATE : Turns out i'm not mad

Cheers guys you've picked up on some points I forgot to mention.

Mainly :

• Not checking the bin folder into source control

Answer 1

No this makes complete sense and is a practice I myself implement on personal projects. Anything under the bin folder should be treated as property of the msbuild / Visual Studio environment.

While they both take great care to only delete the outputs they know about, it's possible for the user to not fully understand what is the build output and copy over a build output and consequently have it deleted during a "Clean" style operation. It's also possible for other tools to be more aggressive here in cleaning out DLL's. I myself tend to nuke the bin directory from time to time if I think the build process is looking at stale data.

Additionally having a ref's location gives you a single place to update references for a collection of projects within a solution. For me it's a very natural construct.

Answer 2

I have no idea if you're insane, but we followed the same practices at the last place I worked and I've carried them over to my own work. The /bin and /obj folders are outside version control and something I never touch. They basically don't exist as far as I'm concerned during development. All included DLLs sit in another folder and are referenced.

Answer 3

I think of the bin folder as being transient, it is a place for the full working compiled application to go.

We place any external Assemblies in a directory called Assemblies. Many others use a directory called lib. This separates idea of something that is needed to compile the application from the compiled application itself.

Answer 4

That's right, you don't want to put referenced dlls in the bin folder. If you are using version control, bin and obj folders should always be completely excluded.

All referenced dlls should be included under version control, preferably in a separate subdirectory under your project's trunk, so that everyone has all necessary sources and references for each clean rebuild. bin folder must easily be recreated from scratch.

That's something that I believe most people will expect when checking out your source.

We also include a _READ_ME.txt file in the root of the project, stating additional info on tools and stuff needed to batch-build the project (nant, perl, etc.), so there may be some specific differences from time to time, but never surprises of this kind.