If there are a lot of projects, then the chances are that it's a windows forms application.

Such an application typically creates a startup form in the Main() method and displays it. The form then sits there waiting for some user interaction such as pressing a button, opening a menu or typing text into a textbox.

There will be be methods in the form class which handle all these events. Some events may open other forms, call methods in other classes to do calculations etc. and so forth.

So, I don't think there is an alternative to understanding how all this works but to step through the code line by line in the debugger, press buttons etc. and see where it leads you.

somewhere in vs (I forget where off the top of my head) there's a dialog which contains build dependencies which should give you a pretty good idea of the dependency makeup of the system. Most of the projects are probably dll's which are referenced by the main application. the main app will likely have dependencies on the other projects which it uses at various times in the app.

most of the projects I work on have very complex large spanning dependencies so much so that we developed a large series of in house addins for visual studio like our reference manager which manages which versions of which assemblies various projects use, and resolves & downloads precompiled versions (from our build machine) of each to keep from having to have huge solutions like that.

one thing you can do to make your life easier (at least in my opinion) is to create post build events that copy your dll's over to some "build" folder by assembly / version number on every dll project, and add references in the apps that use them from that common build location. this way you can build the dependent dll's on their own and work independently on the apps that use them.