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

From @Mike-EEE on May 12, 2016 8:5

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.

Copied from original issue: dotnet/roslyn#11263

[asbjornu]

Yes! I have nothing left to add. I think we’re done here.

[davkean]

@Mike-EEE I appreciate your drive and enthusiasm on the project format, however, we have no intention of changing the project format to XAML or any other new format. You’ve got some great ideas, however, large sweeping and cross-cutting feature suggestions that affect many teams across Visual Studio are better filed on http://visualstudio.uservoice.com (which I believe this one already has). Issues, features and bugs filed in this repo are intended to be actionable work items that a dev on our team or the community can pick up and drive to conclusion. This is not one of those issues.

Based on the fact that we’re sticking with the existing MSBuild format, if you have actionable suggestions help improve the existing format, or bring some of the project.json features across to csproj, feel free to file them. Otherwise, I’m going to close this issue.

Regards, Dave