I suggest you ...

XML format of solutions files (.sln)

Current format of solutions (.sln) files is very complex and is not XML. Current format prevents to make the merge operations and various automation actions. Visual Studio solutions files must be in recognized XML format (like MSBuild files).

509 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Alexander Biryukov shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Jesse McClusky commented  ·   ·  Flag as inappropriate

    They should really just turn Solution files into Traversal projects, since they both fill essentially the same role, and then VS would be compatible with MSBuild's Traversal projects.

  • Richard Matheson commented  ·   ·  Flag as inappropriate

    I don't feel strongly about the format of sln files: XML, JSON, Yaml, Text. Any is fine, as long as it's merge tool friendly and avoids guid soup

  • Anonymous commented  ·   ·  Flag as inappropriate

    SLN files are a disaster. It's a disgrace that essentially all other popular environments have easy-to-use, well known human-readable formats for project management while Visual Studio users are left to handle the atrocity that is the SLN file format.

  • Marcel Gosselin commented  ·   ·  Flag as inappropriate

    Different problems with current format that prevents merging and need to be addressed:
    - Project is referenced in multiple places
    - SourceControl section: get rid of this it does not belong in the solution. Location of file on disk should give us the workspace whatever the type of source control. With TFS, this keeps on checking out the solution file anytime I open it up in a different branch.
    - GUIDs: we reference Project Files and Solution Folders, there should be a total of 0 GUIDs
    XML format would allow putting Solution Items in a hierarchical way
    - ProjectConfigurationPlatforms section: too verbose and would need a big change to get rid of GUIDs

  • Mark Zuber commented  ·   ·  Flag as inappropriate

    Bumping this one. SLN format has to go. It's a total mess. Can we please just use VisualStudio with "pure" MSBuild (dirs.proj traversal, etc)? This would allow the right level of customization in the build process, stop VS from being so "helpful" (i.e. not helpful) with project configurations, enable easier cross-project consistency (e.g. code analysis, platforms, outdir) while still giving us the great in-IDE functionality (intellisense, cross project refactoring, code discovery, etc) that we like.

  • Sanjeev Manickam commented  ·   ·  Flag as inappropriate

    Merging project and solution files can be tricky.

    Main thing - get rid of GUIDs!!
    For .sln files, consider grouping data by project, so that when a project is added or deleted, it only effects one section of the sln.

  • Piet-Hein Heemskerk commented  ·   ·  Flag as inappropriate

    Please also extend the .NET namespace Microsoft.Build.Construction (see: http://msdn.microsoft.com/en-us/library/microsoft.build.construction.aspx) to support this new format, both for reading and manipulating the
    Using reflection I found that there are already some internal classes that deal with solution files: SolutionParser, SolutionProjectGenerator and the enum SolutionProjectType.

  • Keith Hill commented  ·   ·  Flag as inappropriate

    BTW a perfectly suitable and logical XML format would be to use MSBuild for the solution file format especially considering that MSBuild has to generate a temp msbuild file for the solution anyway, in order to build the solution.

  • Keith Hill commented  ·   ·  Flag as inappropriate

    Yes! The current SLN format is a mess when it comes to merging between branches. Many times I have to just accept either the target or source version of the SLN and recreate the appropriate changes to the SLN file. This is *unacceptable*! Also, doing a diff on a SLN is also painful given the idiotic numbering scheme SLNs use to number each project. I also agree with the comment about all the incomprehensible GUIDs.

  • Troels Thomsen commented  ·   ·  Flag as inappropriate

    Please sort the project entries in the solution file (and file entries in project files for that matter) alphabetically. By doing so, you'll reduce the risk of two new entries causing a merge conflict as they statistically will be distributed throughout the file.

  • Stefan Schor commented  ·   ·  Flag as inappropriate

    Merging of solution files is realy a pain.
    Please change the format that merging getting easier (no more "array" counters).

Feedback and Knowledge Base