There are can be at least two completely different things which may give different results. It depends on what you really need. (It's a good idea to start all questions from explanation of your ultimate purpose.)
First one is: you can extract dependency information as it is prescribed in the solution file. This does not reflect real dependency, it only shows what the author of the solution thinks what should depend on what (plus dependencies Visual Studio was able to figure out automatically). This way does not require the projects to be built, and you don't need the target assemblies to be in place. To do it, all you need is just the ability to parse simple data from text (a text of a .SLN file) and apply some logic. You can create few different solutions for samples, to see how the file is structured.
Unlike XML-based MSBuild project file format, the format of the .SLN files is not really documented.
[EDIT] Even though the .SLN file format is probably not documented, you can use access data not directly, but using the solution document interface
; please see Solution 2. [END EDIT]
The second thing is: you can build all the solution (so you will need all projects to be buildable) and perform the analysis of dependencies based on the compiled binary assemblies using Reflection. This is a pretty simple thing. Here is what you need:
Load some assembly to be analyzed based on the file name of its main executable module:http://msdn.microsoft.com/en-us/library/1009fa28.aspx
When this is done, obtain all referenced assemblies:http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies.aspx
For each referenced assembly, load it using the assembly name object obtained for each referenced assembly on the previous step:http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.aspx
Load each of referenced assemblies by their respective instanced of
Do it all recursively to produce the whole dependency graph. Easy enough.—SA