Project System: Please Consider POCO as Schema for Project File/Structure

[Mike-E-angelo]

I (unfortunately) made a lengthy, somewhat off-topic post/rant about this in another thread yesterday so I am going to throw it down here in a dedicated issue and see how it goes.

There's talk about the new build system. There has been previous efforts over at MSBuild to examine the build system and improve upon its format. These were ultimately denied, expressing a "better safe than sorry" (huh? 😛) perspective. So, with all the energy/enthusiasm/magic over here, this appears to be the new lightning rod for developer creativity. 😄

My ask is simple: Continue to use the XML format (or even JSON), but move away from the element mapping-to-POCO strategy and make the csproj/xproj/proj file a fully (XML or JSON) serialized POCO instead, so that at the very least we know the precise POCO (and definition/schema) that we are dealing with and constructing. This helps not only developer experience (and thereby sanity 😄 ) but also any tools/designers that wish to build off of it.

Currently, the project file looks like something like the following:

<Project>
 <ItemGroup> ... </ItemGroup>
 <PropertyGroup>... </PropertyGroup>
</Project>

This is great for defining arbitrary data in a file, but it is completely useless for someone who opens up the file and wondering: "what the **** is a <Project /> element?!"

The above design requires at least three artifacts:

1. The data file itself, expressing the data constructs (.csproj)
2. The schema file, defining what is allowed (.xsd if in XML, and I have never seen one in my 15 years of .NET for a .csproj file!)
3. The POCO that ultimately gets created from reading in the data file.

Oh but wait, there's more! Due to the above design, I bet you there is at least a fourth artifact!
4. The mapping class/utility that reads in the data file as an XmlDocument and laboriously reads in element by element, attribute by attribute to create and instantiate the POCO object(s) with their initialized values. OH THE INEFFICIENT HORROR!!

Conversely, if we take a page from Xaml file design, we have the data file's schema baked right into the file by way of the class definition. As a result, we only require two artifacts:

1. The data file (.xaml)
2. The class definition file (.cs/.vb)

This is a MUCH easier to design to produce, maintain, and manage. Tooling can tie right into the class file (using Roslyn??? 😄 ) and get all the information it needs. Developers do NOT need to hunt and chase down schemas in some arbitrary, hidden location (registry?! LOL, might as well be!) to figure out the file they are working with!

This is a very (relatively) simple design improvement that will make a world's (universe's!) difference in project look and feel. I cringe every time I have to go into the .csproj file because it is SO ARCANE AND MYSTERIOUS TO WORK WITH!

Finally, by using a class definition as the schema, another headache that this eradicates is the inconsistency between camelCase and PascalCase when declaring/using symbols/attribute names within the file (ALL THE INCONSIST!).

Anyways, thank you for any consideration and dialogue around this idea.

[bbarry]

(.xsd if in XML, and I have never seen one in my 15 years of .NET for a .csproj file!)

The xsds are in your msbuild bin folder: C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild

It doesn't help much (the xs:documentation tags almost look like they are generated by some ghostdoc-like tool; for example is documented as "An MSBuild Project" in Microsoft.Build.Core.xsd), but they are there. There are a few useful comments in the file though.

[Mike-E-angelo]

The xsds are in your msbuild bin folder: C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild

LOL... right, of course... EVERYONE knows that! ;) thanks though, @bbarry. One less mystery to worry about. :)

Does it make sense what I am saying with POCO definition vs. .xsd schema approach? If POCOs were used then there wouldn't be a need to store these xsd's in these highly intuitive, accessible, and discoverable locations. 😛 I am open to feedback and would definitely appreciate another perspective!

[bbarry]

I suppose it means the POCO is the xsd...

I really don't care what format is used or what intermediates are involved between an on disk representation of a visual studio / msbuild project and some set of tasks occurring (as long as they work). I do care that the on disk representation is:

• discoverable
• play nice with source control (see VS 2015 RTM - csproj xml node Project\ProjectExtensions\VisualStudio\UserProperties attribute order differs based on machine that saves file #6556)
• human readable and hand editable
• assisted by tooling when modified in an appropriate editor (VS)
• extensible
• provides a single point to drive interoperability of various components used to build the system (by modifying this file I could define compiler directives for Roslyn, manage Nuget packages, drive Grunt, test runners, static analysis programs, generators, filesystem operations and whatever else someone creates a tool to do something related to my build process)

[Mike-E-angelo]

Excellent list @bbarry. That sums it up nicely and captures my sentiment as well.

[davkean]

This issue was moved to dotnet/project-system#37