ASP.NET and Visual Studio - Adding project references vs Bin Folder DLL

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 Telerik, etc. I was noticing that they were installed these third party tools, hunting down the DLL files, copying them into the bin and then adding a reference to the project which points to the file in the BIN. To me, this doesn't seem like normal practice.

I was under the impression that if you just dump a DLL in the bin folder, you don't need to add a reference, it's just available? Reason being, at my last job we used a few class libraries we built in house for data access and just dropped the DLLs in any new websites (not webapps) that we made. I don't recall every having to add a reference开发者_如何学运维 to get it to work.

So, can someone explain best practices on how to add third party references to your web app? Do you add the reference from wherever the DLL is installed in the system? If so, do you check copy local so it copies to the bin? Do you just copy the dll to the bin and that's it? Do you copy the dll to the bin and then add a reference to it there?

Sorry, I'm sure this seems like a simple question, but I'm confused by the two seemingly different methods I've seen used.

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.

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:

1. Build servers are happier, need less maintenance and are less brittle.
2. We have a history of releases and can explicitly control versioning for each solution/project by setting the revision number on each svn:external. For example your trunk code may be using latest Telerik version, but your release branches are using old versions.
3. We can share 3rd party assemblies for different projects, and be confident they are using the correct versions.
4. We're not relying on developers installing or upgrading to the correct version, yet they can still add and test new versions without interfering with other projects (assuming you have explicitly defined the revision)
5. We can test new versions, but easily go back if things don't work.

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.

2013 Update

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.

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.

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.

I always preffer to have project reference rather than having DLL reference. Below are the main reason for it.

• The project, which is adding the reference of other project, will not be up to date.
• Any change to the referred project will not directly reflect. User has to manully delete the old reference and add new reference.