1
votes

I have a solution with several projects that all reference a common set of Microsoft.Practices libraries. Right now, these libraries are in the bin folder of one of the projects, and grouped under a solution folder called 'DLLs', and I don't like this at all. A bin folder should remain an output folder, and dependencies shared among projects should not be hidden in the 'output' of one project.

I would ideally just like to add a physical folder to my solution, move these libraries to that folder, and update all project references to point to that folder, but I can't add a physical folder to a solution. An almost acceptable solution is to create a new project, with no source files, and move the libraries into the physical folder created for that project, and so on.

What are accepted good practices for scenarios like this?

3

3 Answers

1
votes

I've added solution folders, or placed the libraries in an already existing "common"-project.

1
votes

Our project/solution structure look like this:

xdev\companyname\projectname\solutionfolder..

Our common libraries, which are used in several projects lies here

xdev\companyname\projectname\libs..

That works great for us. There is no need to have the assemblies in the solution, in my point of view. If you need a solution wide library folder, so put this into the companyname folder. It's only a logical structure of folders, nothing else ;-)

0
votes

The typical way is to create a Lib directory in the root of your projects directory and place your dlls there. No need to have it as part of your solution. But if you do want it in your solution, you can always create a solution folder and place them in there (right-click on the solution, expand the Add menu, select "New Solution Folder").