I just started a new job yesterday and this is only my second job working in ASP.NET. We were setting up my dev box and were having trouble with some third party components like
Usually I just drop them in the bin, unless it is part of something that isn't that simple. Sitecore for example installs itself and has a couple of folders that it likes to use for putting some of its own code to give an example of something non-trivial.
It depends on how your project is set up. If you want to precompile your site (and get Intellisense to work properly) you have to have a Visual Studio reference. But anything dropped in the bin folder will be automatically loaded by ASP.NET at runtime... so it's possible to access that assembly's controls/objects in code behind without adding a project reference.
For small projects I just throw the DLL into the bin and add reference. For more complex sites/projects, I have a dedicated "library" folder for third party add-ons and code.
Si is very correct there. Also: keep your bin folder for results of builds/compiles. Like said before use a "library" folder to link to. I even do this with devexpress.
Normally by installing devexpress it will install its dll's in the GAC, and you can reference them like you reference the standard .Net dll's. But for version control it is much easier to use a library folder.
In that way, you can be sure that everybody uses the same version of devexpress (the one that is in sourcesafe) to test their code, and you will have less problems with code that compiles on your machine, but does not on another.
We version control our 3rd party assemblies using Subversion, then pull them down via svn:externals into a sub-directory of the solution or project in question, which then references them (and copies into bin).
This provides quite a few benefits:
So a little more working setting things up, but I think it's worth it. Note that we don't version control (svn:ignore) our bin and obj directories, and the 3rd party assemblies are in the same Subversion repository, referenced by relative pathing.
FWIW: Subversion 1.6.6 fixes an annoying bug for file based svn:externals. This means you can choose one or more files (e.g. assemblies) from a directory instead of having to pull the whole directory down.
With the rise of NuGet, consider hosting your own feed via a local server before opting for using svn:externals, simply because it gives you all the same benefits, plus it's baked into Visual Studio via the Extension Manager and provides for better information and meta-data, e.g. being able to let developers know when there is a new release.
The only caveat would be to host your feed using a Win2008 or higher server, as I ran into some issues with our old Win2003 server using SSL with windows authentication to secure the feed. I believe this was due to the older version of IIS used in Win2003, but couldn't verify.
I always preffer to have project reference rather than having DLL reference. Below are the main reason for it.