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).
Piet-Hein Heemskerk commented
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
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
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.
Crispin Horsfield commented
With an XML Solution File, it would be useful to have the ability to add comments and tags.
Troels Thomsen commented
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
Merging of solution files is realy a pain.
Please change the format that merging getting easier (no more "array" counters).
The configurator commented
And get rid of those crazy guids which make changes incomprehensible.