views:

35

answers:

2

We often have a set of common core libraries that for some of our development we want to think of them as dll references and thus just reference the dlls and not include the project file.

Other times we need all projects for an intimate debugging session. I can't just have Uber.sln and Core.sln as the references are in the project files. I've had this question for several years on different projects but do not have any solution other than having an Uber.sln with the 50 projects.

Any ideas / hints / directions welcome!

+1  A: 

As long as the DLLs are built with Debug and you have the PDBs, you dont need to have it included as a "project reference."

It will prompt you for the source code, or you can just open the source code in the solution and set a breakpoint.

http://stackoverflow.com/questions/861291/how-to-show-source-code-in-debug-when-using-lib-and-dll

Nix
+1, yup. It rarely has a problem finding the .pdb file either, as long as it is still located in the original build folder.
Hans Passant
+1  A: 

Develope shared dlls in their own project or projects. Compile them and add them to a lib folder in your projects which reference them. Create a dev tree like this:

/lib
 shareddlls go here
/src
 solution.sln
 /projectfolder
  project.proj
/tools
 testing frameworks

When you debug in VS and go into your own dlls you should still be able to see the code so no need to add the shared dlls to an uber project. If you cant see the code then handle it as a black box. Debug what goes in and what comes out. If it is not what you expect then the issue is in the shared dlls. Go and debug them in their own projects.

Use a testing framework to test your shared dlls in their own project.

skyfoot
There are times when you want to develop features that cross the shared dlls and the application dlls. At those times having one large solution pays dividends. It just seems to be a way of working that isn't supported by MS.
Squirrel
@Squirrel To me that is a bad design. Each class should be responsible for one thing and similarly projects (dlls) should group similar functionality. Strive to remove dependancies.
skyfoot
Let me rephrase that, quite often you need a debugging session where you have to follow a request from the top level of your server into the 'component' dlls. You realise there's an issue in the component that needs fixing but to do it when the component is a dll you need to fire up the component solution, rebuild the component and then take those built dlls and update the dlls that the application solution / project is pointing to. All in all it's a bit of a faf so we have one large solution. neither option is ideal - does this scenario sound familiar or is it just me?
Squirrel