we are working on many different applications where each application has its own VS solution (and of course a CS project). Additionally there are many libraries (also CS projects) that are shared between the applications and are included in the VS solution so that you can debug during startup phase of the development.
We also have a "master" solution that contains all projects in one big solution for refactoring issues. Because VS does not support "solutions in solutions" we have to maintain also this master solution. We are talking about 300 assemblies.
Now a point is reached where it's helpful anymore to have all CS projects as ProjectReference in the application solution anymore. For example we have a library that does the CUDA support which can be compiled once and then used as a regular Reference.
The only problem here is that there are occasions where you need the ProjectReference back again when you need to debug into a problem that can only be verified when it runs in conjunction with the main application and cannot be verified in a normal test case.
One option would be to maintain two projects, one for debugging and one for working. The only problem is that once you debug and you need to use the ProjectReference the dependencies cascade down the whole project tree.
For me it feels like that I need two CS projects for each project. One that only contains References and another one that only contains ProjectReferences. Mixing could be a problem. The question is, if there is something automatic where a Referency-only project can be created from a ProjectReference-only project?
How do you solve something like this?
