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).
Marcel Gosselin commented
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
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
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
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.