VS Solution, projects vs dlls best practice

问题:

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. This is great when needing to debug within the solution but in all other situations it seems pointless and more space taken up in the solution explorer.

Also another positive or negative is that if that library is updated by someone else in the company and I then build another application which uses the same thing they could possibly have broken the build. If for whatever reason that cannot be fixed with the current application then you could go back into your source control and roll back to an older version, but this seems a bit too OTT.

I was just wondering what other people's thoughts on this subject are. What do you normally do, reference the dll or do you add the project to your solution.

回答1:

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.

回答2:

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.

回答3:

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?