Parsing a Solution File

There's a new challenge up at Code Blog.  This time the tests are for something a little more real.  The aim is to parse a Visual Studio SLN file.  I admit to having a vested interest in some code to do this.  I am sick to death of poluting my test code with explicit knowledge of where project output directories are located ('bin\Debug' or whatever).  I really want to reference my project directories by name.  For example, 'Projects.Find("MyProject").BaseDirectory'.

To to this I need to be able to locate and parse solution files.  I hope people find this potentially useful enough to submit a few entries.  I do have some working code, but I'm interested to see how other people go about tackling it.  So please, subscribe to the feed and make your submissions!

4 Comments

  • Hi, I run the VisualStudioObjectModel workspace over at GDN. I haven't done much lately (still alpha style code), but I do have a SolutionParser in the works. It's based on a finite statemachine. The principle is simple. You create a new SolutionParser and pass it an empty Solution object. Next, you read a line from the solution file, pass it to the current state which classifies it using regular expressions to know the next state. In the current state, using a switch statement on the result of the classification, you reuse the regular expressions (actually the groups) to get the values from the line you're interested in. Then you interpret the values and apply them to the Solution object. You return the next state, read a line and start over again, until there are no more lines to parse. Hence you gradually fill up the Solution object as you parse the solution file.

  • I use VisualStudio object model (progID is VisualStudio.DTE) to get at all the information in a solution. All this COM interop is a pain but the advantage is that I am then using the logic built into DevStudio itself to figure out things like dependencies, output paths, etc. I needed a method that would always work and I figured that if I wrote my own and reverse engineered what they had done I would eventually run into something I handled incorrectly and I would always be debugging that section of code.



    That being said, even when using their DTE object to determine output paths I ran into issues. First, not all projects in the solution are VSProjects (i.e. a "standard" project); some are MSI installer projects (I needed those output paths too). Second, even when dealing with a standard project the means to get at the output path varied based on the project type. The output path is contained in a string dictionary of configuration properties, but the key can be different based on the project type, and not all projects have output paths.



    The other PITA is that with large solutions it can take a LONG time to open it up using the object model.

  • Just wait for Whidbey. It uses the new MSBuild project/solution file structure.

  • I have been searching for this....

Comments have been disabled for this content.