Whenever I have a library that use across different websites/ applications I\'ve always just added the library\'s project into the same solution and reference it from there.
Keep the library in some shared folder between projects, and just reference it. That way when its updated, the changes will be persisted everywhere. For debugging, i think if you keep the .pdb files for the library handy then you should be able to step into the dlls, however, should you be concerned with debugging a library?
We keep our production Dlls in a well-known location on a network drive and reference is via the DFS UNC path (no drive letter). This way we can have different versions of the library in use at the same time and updates don't break code/force a recompilation until the newer version needs to be used. A standard naming scheme can be used to ensure that if a project always wants to use the latest version it can.
You could also register your dll in the GAC. The GAC handles all referencing, versioning etc and is secure. Having assigned a strong key which is a pre requisite for dlls sitting in the GAC you have a secure way of accessing Dll's and where you are using a shared server this can be invaluable. Your sites which use this dll have a central port of call for the assembly. The GAC has a whole host of advantages with several articles on MSDN and no doubt hundreds on google dedicated to it.