(b) with a custom build step you can embed the pdb file into the assembly as embedded resource. not recommended though. the best practice I believe, is to suppl

(b) with a custom build step you can embed the pdb file into the assembly as embedded resource. not recommended though. the best practice I believe, is to supply a symbol package in parallel to a nuget package. _edit: there's also symbol server_ embedding debug symbols into assembly would be sometimes problematic, especially when you have public and private symbols -- signing three versions of the same assembly is not really a good idea. (a) (c) I can feel you.. But here's what I've done to this problem: 1. use cmake for the source tree. this way you don't have trouble opening the tree as a whole. 2. in visual studio you can have both the cmake view and a solution view -- you can open a solution right from the cmake view or switch to another. 3. in this way, a solution becomes a smaller unit to organize multiple projects together. in case two projects do not have strong coupling, separate them in different solutions, and use a local nuget package source to reference. 4. of course, you'll have to roll some custom cmake script for managing nuget packages. I've done some work on this, here: https://github.com/Microsoft/GraphEngine/blob/master/cmake/FindDotnet.cmake https://github.com/Microsoft/GraphEngine/blob/master/cmake/F... I've been using this approach in a few of projects at work(and also OSS ones). Insofar people are happy with it.