Please Consider Improving Project Format and Structure (Serialized POCO/Format Agnostic)

[Mike-E-angelo]

Going to try this again, but hopefully with a better defined ask. The request is not to support a particular format, but to improve the MSBuild system overall so that it can support any format, while also making it more accessible/discoverable by tooling and (possible) designers.

Based on the current climate of .NET Core having its project.json merged back into MSBuild, this topic might get a little more interest conversation. Also, the Roslyn team is sending developers your way, so, there's that. :)

Use Case: Developers REALLY like their file formats!

Problem(s):

1. MSBuild format is rooted in an arbitrary, not well-defined/known schema (difficult to explore and discover).
2. MSBuild project structure can only be defined/edited in XML.
3. MSFT development ecosystem (for better or for worse) is now comprised of two camps: web application developers and native application developers each has their own way of doing things and neither really likes the approach of the other.

Suggestions:

1. Create a well-defined, well-known .NET object model that defines the Project Model (Project API). Visual Studio then loads (and saves) these as POCOs on disk. In this design, there are no arbitrary schemas or data files, but 100% serialized POCOs which are read and saved to disk. Another issue on Roslyn's board goes into more detail around this.
2. Adopt a "Bring Your Own Serializer" strategy. Adding a new format/type is as simple as installing a Visual Studio extension (or even auto-detected and installed for you upon detection/initial file load). To start with, JSON5 and XML should be supported out of the box, but developers should be able to bring on any format they wish, such as Xaml, Yaml, etc.
3. Allow (optional) naming extensions for projects to help identify stored format. Examples:
   • MyProject.csproj.json5 <-- C# Project serialized as JSON5
   • MyProject.vbproj.xml <-- VB.NET Project serialized as XML
   • MyProject.fsproj.xaml <-- F# Project serialized as XAML (OH YES I WENT THERE!!!)

Those are off the top of my head to get the conversation started. All of these are open to feedback of course and I would love to hear the thoughts of developers around this. Thank you for any consideration and/or support!

[SolalPirelli]

I think you're vastly over-estimating the demand for different file formats. Who really cares about XML vs JSON? And more importantly, are there enough people who care enough to justify adding complexity to the entire build system?
The current problems with MSBuild files are historical: they're meant to be read/written by VS tooling exclusively (and not humans), they don't support packages as first-class citizens, etc. . XML is not a problem.

[Mike-E-angelo]

Thanks for your input @SolalPirelli. I am not sure what you mean by adding complexity. The solutions/goal is to reduce complexity while also satisfying developer (and organizational) preferences. Even if the tooling is meant to be used by VS/IDE exclusively, that does not mean that humans don't get their proverbial hands dirty with it, and they do all the time. The process for doing as such is very clumsy and awkward (which I believe you allude to via "historical").

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading? :smile:

[SolalPirelli]

I am not sure what you mean by adding complexity.

Adding support for multiple file formats necessarily increases complexity. It means adding a public API that third-party providers will use, which will definitely cause headaches when new items are added and it turns out providers were doing crazy things to enable DSLs.

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.
The exact markup format does not matter, what matters is that the resulting format is editable by both humans and programs, adapted to current needs, and prepared for future evolution. There's nothing in JSON that makes it clearly better than XML in that regard. If anything, JSON is worse because it lacks comments.

[aolszowka]

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

I will agree with regards to documentation and ask that the current XML format be better documented; but as far as a switch to JSON I see little to no technical gains. Why not take those resources that would be wasted on such a system and instead put them towards improving the MSDN docs?

As per Raymond Chen every feature starts out at -100; what are the gains that get us to Positive 100?

[Mike-E-angelo]

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.

LOL!!!

I hear you. As for the API. Yes, that is the goal here. To (ultimately) have a well-defined/documented/accessible project API that we all know and have availability to, in case we want to know the file (project) we're actually describing. :)

When you open a .csproj file now... can you in all honesty say you know each and every element within it? The schema is difficult at best to discover and browse. Whereas if we were using a well-known API (.NET POCOs) then this becomes a snap.

If anything, JSON is worse because it lacks comments.

Agreed. But not everyone is agreement with this. And also, I am suggesting JSON5, which allows comments. Finally, the serialization is intended to be an implementation detail, and not supposed to be something that is part of MSBuild, per se. It just has to support it.

[Mike-E-angelo]

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Well dudes... WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?! LOL. I guess I have some baaaaaad luck then, because I have been harping against the project.json movement for over a year now and it has seemed to have been an uphill battle, to say the least!

I personally am very much more in the XML camp (I would actually prefer to see Xaml), but I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

[Mike-E-angelo]

And also, I do not want to "switch to JSON" ... but to simply support it as a serialization mechanism. If we're working with well-defined/known POCOs from an API, what matter does it make the format it is serialized/deserialized in?

[aolszowka]

When you open a .csproj file now... can you in all honesty say you know each and every element within it?

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means. I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

The schema is difficult at best to discover and browse.

This is the primer for anyone coming into MSBuild that needs to start with https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?!

Monitoring the progress of MSBuild's open sourcing; trying to assist on StackOverflow under the MSBuild Tag (when Sayed isn't beating me to the punch). #JustBuildMasterThings

I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

I see no reason why both projects cannot coexist; each project should be allowed to fail or succeed based on its technical merits. Instead of chasing tail lights I personally feel that resources are better spent on improving what we have if there is a clear technical gain. That being said I'm not the Product Owner, nor even a Developer, just a well informed end user.

but to simply support it as a serialization mechanism

Again what is accomplished from this?

[shmuelie]

I personally think what we need is a good way for the two build systems to share data, so that MSBuild can import data from a JSON project file.

[Mike-E-angelo]

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means

Wellllll that's all nice and good and it is great to see all your investments/commitments to becoming/being a Build Master, but for a typical developer who simply wants to add a new task to their project to do x, y, z, their objective is to get those tasks in and back to developing code, not spending a week in required reading to figure out the simplest of features.

Again what is accomplished from this?

You're asking me what is accomplished by allowing developers to use the format they most prefer to work in? :smile: Web developers REALLY like their JSON and native developers really like their XML/Xaml. Soooo...

And of course, there are other formats altogether that developers enjoy. By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

[SolalPirelli]

Everybody agrees that we need a less arcane format for build files. I can't speak for Microsoft, but it does seem like they want to move in this direction as well.

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere. Creating a flexible enough API, documenting it and versioning it is far from trivial, MSBuild or otherwise.

[aolszowka]

typical developer who simply wants to add a new task to their project to do x, y, z

It would be helpful to understand what you're asking the project to do. Looking at project.json (I had never heard of this project until today) I only see limitations on what I'm able to do. For one there is no readily apparent ability for me to extend their project system with custom tasks (something any one who utilizes MSBUILD will eventually do).

The concept of native NuGet Package management seems nice; but is hardly novel.

not spending a week in required reading to figure out the simplest of features.

Again if you could tell us those features that you feel are hard to discover and would take a week of reading?

In reality, a significant portion of developers will never find themselves editing the csproj or any other msbuild based file by hand. The vast majority of them are interacting with the system via Visual Studio. Those that are editing in these files generally are reading the documentation or are using wrappers around the system such as TeamCity, Jenkins, or Team Foundation Server (TFS/Visual Studio Online whatever you wanna call it these days).

If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

most prefer to work in?

I'm asking what these developers are doing and why they're not using the tooling provided to them?

By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

This is great in theory; however in practice it results in a contract being formed between Microsoft and these 3rd Parties; Raymond Chen speaks at length about such subjects as they are a recurring theme in the history of Microsoft developed products. Offering such a system results only in additional technical debt, and unless there is an extremely compelling reason most teams are wise to not take on such debt.

But back to your original post as I feel we're far off topic

MSBuild format is rooted in an arbitrary, not well-defined/known schema (difficult to explore and discover).

You need to qualify what you mean by this; the schema provides an XSD by which the project file can be validated http://schemas.microsoft.com/developer/msbuild/2003 this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks. Many community based projects such as the MSBuild Extension Pack and the MSBuild Community Tasks do this.

The format is well documented on MSDN (https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), an exploration of the project syntax is relativity straight forward to me personally.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

Create a well-defined, well-known .NET object model that defines the Project Model (Project API)

Believe it or not what you ask for already exists for MSBuild; however officially it is not a sanctioned binary for third party use and the API's are not guaranteed to change. However based on the widespread usage it has become defacto (probably much to the team's displeasure). The much API in question lives in Microsoft.Build; the most familiar of which to me is Microsoft.Build.Evaluation (https://msdn.microsoft.com/en-us/library/microsoft.build.evaluation.aspx).

Anyone who has done extensive deep dives into creating custom tasks or extending Visual Studio will be familiar with these API's.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

[Mike-E-angelo]

this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks

That sounds like -- and is -- a lot of work. :stuck_out_tongue: The goal/ask here is to make this more of a POCO based model where we are working with well-known/well-defined POCOs, and the objects that are serialized/deserialized are these objects. Otherwise, we are asking developers to add "yet another artifact" with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

I am open to admitting that I might (most probably) using the wrong words in describing my problem. I am fundamentally lazy and don't like thinking about things until it really matters, like you are pushing me to do! Essentially, there are two scenarios here to consider:

1) Build master (experts) 2) Developers (script kiddies/interested in becoming a build master -- hey, that's me!)

I will speak from my perspective (developer -- but I do have a lot of experience with TFS build servers). To start with, I will provide context when I go to open a Xaml file. When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me. Using ReSharper, I can CTRL-B any symbol on that file, and I will be taken to its (decomiled) definition. This happens every time, no question.

Now, for MSBuild, I have to open up the project to edit it. First, it produces a very disruptive dialog if I want to close all files in the project to view this file. Secondly, once the file opens, discoverability is next to zero. Not to mention the conceptual paradigm in play is very awkward. If I I want to get a list of files, I have to work with these PropertyGroup and ItemGroup tags and work with a strange syntax to collect my files.

Whereas in Xaml I could see something more well-formed such as:

<msbuild:Project>
    <msbuild:Project.Resources>
        <msbuild:FileList x:Name="FilesToDelete" Files="SomeDirectory/**.*" />
    <msbuild:Project.Resouces>
    <msbuild:Project.Tasks>
       <msbuild:DeleteFilesTask Files="{x:Reference FilesToDelete}" />
    </msbuild:Project.Tasks>
</msbuild:Project>

(note that is a REALLY ROUGH sketch of what I would possibly like to see in an API model. Please don't make too much fun of it. :stuck_out_tongue: But the point here is that as I am typing, tooling kicks in and I am able to reference tasks as I write them as they are POCOs resolved to assemblies I have referenced.

I'm asking what these developers are doing and why they're not using the tooling provided to them?

That's just the problem. This is no tooling provided to XML editing of MSBuild files. Well there is, but it is very prohibitive when compared to, say, Xaml editing experience.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

Like I said this is just to get the conversation going. Looks like I posted in the right place! :smile: Thank you for providing your input/perspective. I can tell you know what you're talking about! And also, give me your Twitter handle so I can tag you when I get pwned by the JSON crowd. (kidding... sorta :smile: )

[Mike-E-angelo]

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

[SolalPirelli]

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

The ASP.NET team made the choice of accepting third-party configuration models, yes, and I'm sure they had good reasons to make that tradeoff; the fact that they needed to implement multiple configuration providers anyway for things like environment vars and config files probably factored into that discussion. In exchange for that flexibility, they get more complexity.

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument.

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

[shmuelie]

@Mike-EEE The issue is more that you know the XAML APIs and (admittedly) the editor experience is less friendly for MSBuild. But if you really want to learn http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00

[colin-young]

You can count me in the project.json camp, although what I loved about it was the simplicity:

• here's my project name and description
• here are the target frameworks I want supported and here are the dependencies for each
• here are my framework-independent dependencies (more often than not, none)
• done. Here's your NuGet package.

I don't care what format you use to instruct the toolchain to build my project as long as it is documented, I can edit it by hand (because sometimes NuGet just gets confused) and I can use the exact same thing on a dev box as on a build server and they both work exactly the same way.

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

[shmuelie]

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

See https://github.com/nuproj/nuproj by @terrajobst

[Mike-E-angelo]

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument

Again, not making it more complex, but reducing its complexity. It's not just a fad in web development but a viable, popular pattern that has been used for quite some time in .NET. The ask would be to utilize this pattern for serializing objects that are used to describe MSBuild projects in a way that allows developers/organizations/teams to use the format they prefer.

I am starting to get the feeling that we should wait until more developers from the pro-JSON camp find their way onto this thread before attempting to provide a better argument. ;)

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

Haha... that's cool. I learned something new today. Thank you for the link :smile: My idea is to provide a better model (which it sounds like everyone agrees with!) which can then be serialized/deserialized in any format, if that helps clarify my position.

[aolszowka]

with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

Yes; they're used all the time. In your Xaml example its how Intellisense (and other such tools) knows what to present to you and how XML files are validated as "well formed". The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me.

You're asking for Intellisense; again provided by a valid XSD which is automatically loaded as per the directive at the top of every well formed msbuild project file. Out of the box this is only provided for the included "base" MSBuild tasks.

Does the one provided within Visual Studio not meet your needs? Below is a screen shot from one of our build scripts showing this in action:

A reasonable ask I think is to ask for more context documentation here to improve discover-ability; however that is for another subject; one I'd gladly up-vote as I know when I was starting out it was frustrating to continue to reference back to the documentation.

First, it produces a very disruptive dialog if I want to close all files in the project to view this file.

This is a limitation of Visual Studio; not of the chosen file format.

no tooling provided to XML editing of MSBuild files

Again, any XML capable editor can do this; I personally recommend Visual Studio simply because it will parse the XSD and any other included namespace to give you contextual Intellisense/Code completion.

And also, give me your Twitter handle

I've been told I need one; but honestly have never bothered to get on there. Feel free to @mention me anywhere on GitHub though.

[Mike-E-angelo]

@SamuelEnglard yeah I hate to mention Xaml here, because the Xaml that is already in use that is associated (very negatively i might add) with MSBuild is actually Windows Workflow and is really a bear to use (really, EVERYONE hates it and do not want "Xaml" because of it). I personally would like to see Xaml used to describe MSBuild files so it would be more like the current XML approach, but much more well-defined and discoverable.

[colin-young]

See https://github.com/nuproj/nuproj by @terrajobst

Yeah, no. That's still requiring me to duplicate information. The only reason I should ever need to specify some bit on info again is because I want it to be different than somewhere else. e.g. If I have AssemblyInfo.cs in my project and I want the assembly versions to be different than the version of the NuGet package, then I would specify each. Otherwise, setting one should flow into the other.

I should be able to describe everything about my project in a single location. I should also not need to tell NuGet that I want it to take the output of my project and use that in the package. Why wouldn't I want to include that? And if I've already specified which frameworks to generate assemblies for, why do I need to explain which targets are being packaged, again? Pick all of them, unless I tell you otherwise.

Sensible defaults and a mechanism to override them...

[Mike-E-angelo]

You're asking for Intellisense

Actually, no I am asking for more than that (from what I understand). Intellisense completes the symbols, and provides tooltips, but to actually dive into the symbol to take you directly to the class file where it exists, that is an IDE (or tooling, such as ReSharper) implementation detail.

Does the one provided within Visual Studio not meet your needs?

It's OK. But I find the Xaml experience much more expressive and discoverable. And intuitive as well. And I am not entirely sure that Xaml is using .xsd files, unless they are automatically creating them from the class definitions? That seems inefficient as the class definitions are already in memory and available to to the tools. It doesn't make sense to create a whole new file and then use that for navigation/information.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

[shmuelie]

@colin-young because it's all MSBuild you can "embed" it into the existing project and have it pull the information from there. I think I'll fork it to add an example of doing that...

I've added #614 to discuses a better experience editing the XML since that's really off topic for this issue

[aolszowka]

@colin-young

If I understand what you're asking for you want a workflow in which NuGet package creation is more tightly coupled with the build; this is already possible in MSBuild; it would require that you add a new target to your existing msbuild file and then call the target at the appropriate time; if you were using MSBuild Community Tasks you'd call the NuGetPack Task as appropriate (here's a snippet from one of our projects):

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Reading between the lines you want a system that does this for you automagically; I'm not sure that specific business needs should be covered by the tool by default. At some point you will need to customize and modify the tools to fulfill your needs.

[aolszowka]

@Mike-EEE

but to actually dive into the symbol to take you directly to the class file where it exists

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is; all of this can be embedded in the XSD; the version that they have provided and maintained is very simplistic covering only the built in tasks and the various attributes (IE "arguments") to be passed into the task.

And intuitive as well. And I am not entirely sure that Xaml is using .xsd files

Its slightly more complex than that Intellisense will utilize methods such as comment scraping for XML Docs to generate this information on the fly; but the end results are the same.

It doesn't make sense to create a whole new file and then use that for navigation/information.

Why not? The file is created in memory if anything.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

If you look at how MSBuild handles SLN files; they are actually transformed by MSBuild into pseudo MSBuild files prior to execution to avoid the nastiness incurred within them. However that being said I found the format straight forward; if you created another issue page to air your complaints with them I'm sure we can show you how they operate.

They are also editable via the above linked API.

[Mike-E-angelo]

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file. You get clear connection to the data you are describing and the object that ends up using those values. If you have not spent a lot of time in Xaml then it might not make sense to you, but when you have access to your code and can easily navigate through its properties and definitions, you not only get a better understanding of the elements at play, but also for the system as a whole. This is what is so awesome about .NET in general: being able to explore elements and see how they all connect and how they can be utilized.

Why not? The file is created in memory if anything.

Again, I am not sure if this takes place. Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this. And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

if you created another issue page to air your complaints with them

Truth be told, I have already done that here: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

:)

[colin-young]

@SamuelEnglard @aolszowka This thread started from https://github.com/dotnet/roslyn/issues/11235, which was about improving the project definition format. To your point, what I'd like is a declarative project format rather than prescriptive. MSBuild is, by necessity, prescriptive. 90% of the time, I don't care how it accomplishes that because I just want to say, "Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

To me the question is, should the tool that takes a declarative description of a project and produces the requested output be part of MSBuild, or part of something else? But I do feel very strongly that it needs to be standard across all of .Net (i.e. one file format on Windows, Linux, OS X whether you are using the command line or Visual Studio).

[MarkPflug]

@colin-young You can put your version number in an MSBuild file and have your AssemblyInfo.cs (or part of it) generated by an MSBuild task. I've done this for my work projects, because we have ~100 projects that we want to build with the same version. Now, we only have the one place to maintain that version number. This same version property could be fed into the task that builds the nuget packages.

CommonAssemblyInfo.targets:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <PropertyGroup>    
        <Year>$([System.DateTime]::Now.Year)</Year>
        <Version>1.2.3</Version>
        <Company>FooBar Technologies</Company>        
        <Copyright>© $(Year) $(Company)</Copyright>
        <CommonAssemblyInfoFileName>CommonAssemblyInfo.cs</CommonAssemblyInfoFileName>
    </PropertyGroup>

    <ItemGroup>
        <Compile Include="$(CommonAssemblyInfoFileName)"/>
    </ItemGroup>

    <Target Name="CleanCommonAssemblyInfo" BeforeTargets="Clean">
        <Delete Files="$(CommonAssemblyInfoFileName)" Condition="Exists('$(CommonAssemblyInfoFileName)')"/>
    </Target>

    <Target Name="CreateCommonAssemblyInfo" BeforeTargets="CoreCompile">
        <ItemGroup>
            <AssemblyAttributes Include="AssemblyVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyInformationalVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyFileVersion">
                <_Parameter1>$(Version).$(BuildNumber)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCompany">
                <_Parameter1>$(Company)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCopyright">
                <_Parameter1>$(Copyright)</_Parameter1>
            </AssemblyAttributes>
        </ItemGroup>

        <WriteCodeFragment 
            Language="C#"           
            OutputFile="$(CommonAssemblyInfoFileName)"
            AssemblyAttributes="@(AssemblyAttributes)" 
        />
    </Target>
</Project>

Just Import this targets file into your .csproj file. (It might need some tweaks, I sanitized this from the one that we use. This way you also don't need to remember to update your copyright year every time the earth laps the sun.

[aolszowka]

@colin-young @MarkPflug Excellent; you can obviously chain that to whatever task you need; including the packaging of the NuGet Package and pushing out as needed.

"Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

I'm not sure what I'm missing here; this is exactly how msbuild can work; what have you tried?

[aolszowka]

@Mike-EEE

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file.

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system. You can validate this yourself by browsing the source or by Reflecting on the Binaries with your IL De-compiler of choice. You'll see the majority extend from the ToolTask helper abstract class to perform most of the dirty work.

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon.

I assure you I've spent plenty of time in Visual Studio in plenty of projects some of which utilize WPF pretty heavily; but I'm still missing where you feel this is any different than what is currently provided (but I will admit needs to be much better fleshed out).

Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this.

This is the first Google Result for "Intellisense xsd"; it provides a very good high level overview https://msdn.microsoft.com/en-us/library/ms255811.aspx if there is something more you need let me know. The documentation claims it only goes back to VS 2005; which seems to jive as that's when I started using VS.

And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

How do you think Intellisense is being provided to you right now? I'm not sure that you understand what you're arguing here, or maybe I'm completely off in left field as to why you think this is an issue. You realize that in order to gather documentation from XML Doc Comments Visual Studio is creating a structure (that can even be written out to an XML file) that contains the documentation for each function right?

All of that is beside the point; I strongly encourage you to take the time to understand how Intellisense works before continuing this discussion; starting here https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx, here https://msdn.microsoft.com/en-us/library/s0we08bk.aspx, and here https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.language.intellisense.icompletionsourceprovider.aspx

Thank you for that users voice link; I'll direct additional input there as needed.

[Mike-E-angelo]

@aolszowka LOL I think we are definitely getting our definitions crossed here (and don't get me wrong I really appreciate your dialogue!). I understand how Intellisense works from a functional standpoint, but from a technical standpoint, I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference. :smile:

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context. Perhaps this is a matter of approach, but when learning a new API, I and the developers I know spend a lot of time navigating through objects/classes to learn the system. Documentation is really a 2nd thought and rarely used. In fact words get in the way of the real langage, the code! :)

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon

Yikes, this is a very narrow (bordering on close-minded!) view! This might be the case in actually bolting together a task and a "just get it done and never think about it again" sense, but developers (again, the good ones I know) like to explore. When you impede this process (or make it difficult), this provides poor experience. Poor developer experience results in poor adoption and even worse yet poor sentiment for your product.

This is why Xaml developers are really passionate about their Xaml, because of the experience that it offers, and that is part of the goal here -- to improve the developer experience this format and model.

[aolszowka]

I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function.

Actually it does; right under the first header:

"After a schema is associated with your document, you get a drop-down list of expected elements any time you type "<" or click the Display an Object Member List button on the XML editor toolbar. For information about how to associate schemas with your XML documents, see XML Document Validation."

Please understand that in this context schema is an XSD (XML Schema Document).

Furthermore, reading the in-lined link (see XML Document Validation) clearly states:

"The XML Editor checks XML 1.0 syntax and also performs data validation as you type. The editor can validate using a document type definition (DTD) or a schema. Red wavy underlines highlight any XML 1.0 well-formed errors. Blue wavy underlines show semantic errors based on DTD or schema validation. Each error has an associated entry in the error list. You can also view the error message by pausing the mouse over the wavy underline."

And even further:

"When editing an XML Schema file, the xsdschema.xsd file located in the schema cache is used for validation. Validation errors are shown as blue wavy underlines. Any compilation errors are also shown with red wavy underlines."

In an MSBuild file this is implicitly loaded by the namespace command:

xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

The exact same way it'd be loaded in for any Xaml or other XML based document format. This is not unique to any of these file formats but is part of the well-defined XML Document Standard.

The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference.

That is a distinction without a difference; however, it is beside the point.

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context.

I'm not sure what you're saying here; I'm not sure how looking at the source of a Task (for example https://github.com/Microsoft/msbuild/blob/c1459f5cbd36f2c33eafc8f4ff087f6ee84c3640/src/XMakeTasks/Move.cs) gives you any insight on how the task (Move) is supposed to be used from within MSBuild; there is no requirement (although it is good practice) that a usage comment is associated with the code that defines the task.

Let’s for a moment say that they implemented what you described; When you were highlighted on a task name that hitting F12 (Go to Definition) took you to either the reference source or a decompiled version of the currently referenced assembly. What would your work flow look like if you were attempting to use the Task (not Debug the task)?

Yikes, this is a very narrow (bordering on close-minded!) view!

This is a view commonly shared by consumers of any API; understanding how the API call is implemented may serve some desire to understand how things work; but it will not explain to you how it should be integrated with other parts of the API to perform useful tasks, nor what the expectation is of the person providing you the API.

Do you need to know how File.Delete(string) is implemented? How would that change how you utilize the function beyond what was documented for it? What about Interfaces or header files; which give absolutely no implementation details (as is their purpose).

When you impede this process (or make it difficult), this provides poor experience.

For a "Good Developer" this has never been an impediment; even prior to the open sourcing of this project. Microsoft does not obfuscate their code; you could always have looked "under the hood" at the implementation of any of the given classes using any number of the available IL Decompilers.

However, as I have stated before there is nothing to be gleaned from viewing the source to the MSBuild Task that was not better covered in the documentation which at the end of the day is the guarantee from Microsoft.

Good developers also recognize at what layer of abstraction to focus their research time on. Good product owners know where to invest time on features and how to get for what is asked for. Good document writers produce enough documentation such that groveling in the source should be unnecessary.

[shederman]

@aolszowka never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Hi. I'm a professional developer. I was lead developer on several major projects at a top 20 stock exchange. I was the lead solution architect. I knew MSBuild/Team Build better than most of the Build Masters there and assisted them with developing and debugging their builds. I admit, I don't want a JSON based MSBuild. I want MSBuild gone. It'd be nice if it's simpler replacement was an easier format than XML for humans.

@aolszowka I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

I'm in the DevOps camp, yes. I increased my current client's delivery pace over 100% in one year (with less staff), by adopting DevOps techniques. You know, delivering more value to the business in a shorter time. That's what "professional" software engineers do. Oh wait, I'm a "poser". And I don't know what I'm doing if I don't have a drag n' drop interface. Hmm, where is that IDE? Oh yeah, I don't have one installed. Tough to drag and drop in a text editor dude.

@aolszowka Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

Read it. Cover to cover. More than once. Years and years ago. And I still rejected MSBuild. So, wait, by your definition I have intimate knowledge. How can I not like MSBuild? Waiting eagerly for the "well, you obviously didn't understand it" response...

@aolszowka Looking at project.json (I had never heard of this project until today)

Wow. You're dismissing other's viewpoints left and right, denigrating their abilities and making snide comments about them being posers, but you don't know the biggest shake up slated for the .NET Core toolchain? Well, until yesterday, that is...

@aolszowka If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

Yeah, I did. It was called project.json. The environment was .NET Core on OSX. But now they're forcing me to use MSBuild, and I don't wanna, 'cause it's rubbish IMO.

@aolszowka The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

"Kids", huh? Haven't grown up enough? Gee whiskers, if you're calling me a kid, I'd love to hear about your professional experience.

Some developers look up from their environment from time to time and evaluate alternatives. They try out Python, or Java, or Maven, or Scala, or F#, or Fake, or SBT, or TypeScript. And they learn. And they improve. And they judge their primary development environment tools based on what they've seen delivering value elsewhere.

Other developers focus on one toolchain and one stack for their entire career, and never learn anything outside their ambit. They think their primary/only development tools are the One True Way™ and there's no point looking at anything else.

Just some friendly career advice: I've found that the second set of developers are always the ones who get retrenched first, and that they never reach the earning potential of the first set of developers. But hey, that's just my experience after two decades years in the field, just a poser kid.

[shederman]

In fact, here's a screen grab of my Online Kindle Reader:

[aolszowka]

@shederman

What caused you to Reject MSBuild for your workflows and how do you feel the suggested change will improve MSBuild such that you'd reevaluate it in the future?

[shederman]

Dude, it was just pain. I could get it working, but very few devs spent the time or cared. So if I set something up in one project, they didn't transfer it to another. If there was a problem, I had to fix it. Even those Build Masters were clueless with a lot of the stuff. From what I could see, they were not in your league by any stretch, I'm a busy guy, I don't have time to chase after build issues.

I just want something that's easily edited by the devs, presented in a familiar and intuitive manner, and doesn't require complex internal knowledge. And I understand property groups, but for imperative-based developers they're counter-intuitive, and an impedance mismatch.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Is that sufficient for a fully fledged build system? No, it's not. But it is sufficient for microservice based architectures in many cases. We have small, simple services, with simple build requirements. Why do we need this inference system to describe the blazingly obvious? Restore packages, build, test, pack.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine. Again, it's not complex stuff. We're not building an operating system. The complexity is in the deployment and management systems, not the build.

So sure, we'll need some sort of task running system at some point. But does it really have to be inference based? The stream based solution of gulps is very intriguing. Maybe not viable for .NET, but an indication of how you can have a task based system with imperative type logic.

[aolszowka]

@shederman

So if I set something up in one project, they didn't transfer it to another.

Is there a reason common includes or pre-defining projects using Visual Studio Templates did not fulfill this need?

doesn't require complex internal knowledge

The devil is always in the details; there is a balance that needs to be struck between flexibility, complexity, and ease of use for developers who are not focused on such tasks I agree. However I thought MSBuild struck a reasonable medium with regards to the requirements placed upon it.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Perhaps as you say I've "never learn anything outside their ambit" but I'm confused as to what you expect the system to do here; at some point you need to declare your dependencies. Could you provide an example of this?

Why do we need this inference system to describe the blazingly obvious?

Because this system is used for more than just simple Microservices; its used to build everything from a Hello World Application to Complex Multi-tiered systems with numerous dependencies and build requirements. The extensibility provided by MSBuild strikes the best balance it can to meet competing needs.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine.

This requires these additional tools to be shipped along side the proposed build system; with MSBuild these can be embedded within the system itself. If your end goal is to reduce the amount of setup an end developer is doing requiring Powershell or Bash to be configured correctly on the system is simply another (easily automated) hurdle.

I did not see a response to the last part of the question; which was how does this suggestion improve MSBuild such that you'd reevaluate it for your purposes?

I'm not here to beat the drum to say that MSBuild meets all needs; its far from a perfect solution for all end users. I am however here to beat the drum against trying to modify it into something it is not; and cannot be without significant investment that results in a fundamental redesign of the product.

At some point it is better to abandon such a product and move on to one that is better suited to address the needs of its developers.

[shederman]

Is there a reason common includes or pre-defining projects using Visual Studio Templates did not fulfill this need?

I've used common includes for myself, but have always found them a pain as well. You don't often install/update them so they tend not to be in the new machine builds. Causes some hilarity when the devs can't build and are struggling to find out why, when a magic file is needed for it to work.

I've built VS Templates a couple of times, but found it a bit of a waste of time. The templates tend to require a lot of maintenance that doesn't pay itself back.

I think both those solutions would work in a world where I have a team of capable Build Masters doing these things for me. I've had Build Masters at only one client so far, and it'd be a stretch to call them capable.

I thought MSBuild struck a reasonable medium with regards to the requirements placed upon it

Dude, this is the reason I'm engaging with you. I'm not trying to convince you that MSBuild is awful, I just want you to realize that a great many professional and capable development teams find it to be suboptimal for their needs. The medium it crosses does not approach their needs very closely.

The extensibility provided by MSBuild strikes the best balance it can to meet competing needs

Sure. So it's a spork. I want a fork. Others want a spoon. But it's neither. Sometimes you have to be opinionated, and sometimes you have to realise that meeting all needs is not possible or economic. Additionally, most of my complaints relate to the way the extensibility it implemented. There are other ways to do it.

If your end goal is to reduce the amount of setup an end developer is doing requiring Powershell or Bash to be configured correctly on the system

Um, brew and chocolatey. Getting those tools installed is faster and easier than editing an msbuild file. They're imperative, so devs grok them easily without an impedance mismatch. Are they perfect? No. Would a proper build system be better? Maybe. Would MSBuild be better? Not in my opinion, not my our use cases.

how does this suggestion improve MSBuild such that you'd reevaluate it for your purposes?

I'm not trying to improve MSBuild. I don't want to modify it into something it's not.

I want it out of my toolchain entirely.

At some point it is better to abandon such a product and move on to one that is better suited to address the needs of its developers

Agree absolutely! But it was done, it was project.json. And then MS decided to back out of that decision and move back to MSBuild.

I think we're cluttering an issue thread with a lot of philosophical argumentation :-)

Drop me an email to continue the conversation.

[Mike-E-angelo]

I'm not sure what you're saying here;

I think that sums up this conversation to point perfectly. :smile:

Actually it does; right under the first header:

LOL... I appreciate the line by line of the article you asked me to read (and I did, well, glanced over it because I know most of it already. :) ). We are definitely confused here. You are saying that Intellisense uses XSDs to work on an XML, which is accurate, but not in all cases. In my mind, I was also thinking of Xaml files. Intellisense works just fine there without an XSD. Why? Because of the class definition. In this case (and I would argue should be for all cases) the class definition is the schema. I was under the impression that you were saying that the XSD was generated automatically anyways in such cases, which is where I was asking for reference.

you could always have looked "under the hood" at the implementation of any of the given classes using any number of the available IL Decompilers

Right, and what is the amount of effort required to do this? I have to go find a compiler and learn how it works, then navigate to the file and start dickering from there. Converse this with the experience of pressing CTRL-B (via ReSharper -- Maybe F12 also works these days?) on any symbol on an Xaml file and being taken directly to (decompiled) definition. Here the tooling is working with you not against you.

Do you need to know how File.Delete(string) is implemented?

Yes, if I can. Seeing how it is implemented gives me knowledge as a developer and improves my skill, as well as providing me access and visibility into how other developers using .NET (and in the example you provided one who works directly for MSFT!) go about solving problems. Having access to this knowledge ultimately improves my skillset as a developer, and again separates the "good" (knowledgeable/craftsperson) developers from those who "just want to get the job done and move on to the next thing someone is paying me for."

All of this again leads to developer experience. The experience that leads to more knowledge/visibility with the least amount of work/friction is the one that developers will gravitate to and adopt.

What would your work flow look like if you were attempting to use the Task (not Debug the task)?

Now we're talking. There isn't a workflow per se, but more of a tooling access to the information that I require (or are simply interested in). The objective is to reduce confusion and improve accessibility and developer knowledge with a given library and/or API. Xaml development is the best I can think of, which is why I keep referring to it, but I am really open to any system that provides its qualities.

[Mike-E-angelo]

@aolszowka some great discussion here that reflects some of the sort of sentiment I have seen (and was alluding to earlier) towards MSBuild: https://github.com/aspnet/Home/issues/1433

[aolszowka]

@shederman

I've used common includes for myself, but have always found them a pain as well. You don't often install/update them so they tend not to be in the new machine builds.

Is there a reason deployment methods such as NuGet were not used to keep these up to date (you also mention chocolatey and brew, both of which can do this as well)? Or an even easier step of checking them into the root of the project so they're updated at the same time your Developers use Version Control to pull changes?

Is that the only pain point your encountered?

I've built VS Templates a couple of times, but found it a bit of a waste of time. The templates tend to require a lot of maintenance that doesn't pay itself back.

I guess I found them no more work than editing the MSBuild file for your project; again with various deployment/environment management tools it allows you to quickly update them to the standard you need your developers on.

I've had Build Masters at only one client so far, and it'd be a stretch to call them capable.

Would you by chance go as far to call them poser kids?

Dude, this is the reason I'm engaging with you. I'm not trying to convince you that MSBuild is awful, I just want you to realize that a great many professional and capable development teams find it to be suboptimal for their needs. The medium it crosses does not approach their needs very closely.

And the reason I'm engaging with you is apparently I'm in the group of developers that likes to understand the issues other devs have ran into (IE the limitations to the tooling); understand what their solution to the problem was; and then work out how I'd solve a similar class of issue should I run into it either in my job or when someone posts a similar question on StackOverflow.

Additionally, most of my complaints relate to the way the extensibility it implemented. There are other ways to do it.

I'd like to understand this; what struggles did you encounter.

Um, brew and chocolatey. Getting those tools installed is faster and easier than editing an msbuild file.

Sure is nice when you cut off the potion of that comment that mentions (easily automatable). By this logic though the above solutions should have been eaiser to deploy; you however said it was a pain because you don't open install/update devs?

I'm not trying to improve MSBuild. I don't want to modify it into something it's not.

Yet you're here; on this particular issue?

Drop me an email to continue the conversation.

Seeing as you didn't leave your email address please feel free to hit me up first its my git username at a popular mail service from Google.

[Mike-E-angelo]

@SamuelEnglard

I believe you meant to mention @shederman rather than our esteemed @SamuelEnglard. Or did I just step in it again? :smile:

(excellent questions btw!)

[aolszowka]

@Mike-EEE

In my mind, I was also thinking of Xaml files. Intellisense works just fine there without an XSD. Why?

Because as I stated in my above post your Xaml file is including the xmlns and Visual Studio is performing this required task for you; in addition it is also performing several XML Doc scraping techniques to gather the information it needs.

Right, and what is the amount of effort required to do this?

None, you're already doing it yourself; you yourself mention you use ReSharper; included in that suite of tools is dotPeek which is one of many IL Decompilers commercially available. This is what is occurring when you hit Ctrl+B in your environment. Other such tools would be Reflector, IL Spy, JustDecompile and good ol' ILDASM.

tooling access to the information that I require (or are simply interested in)

The source to this tool is now openly available (with comments); What you are asking for basically amounts to an improvement to link you directly to the reference source (something done in newer version of Visual Studio such as 2015 when browsing to known sources such as the BCL).

While there are merits in looking at code this does not help someone new to MSBuild understand the system; a design goal for your proposed improved system if I've understood everything you've said here. I just don't see how it gets you there.

I agree this whole thing reads like the XY problem.

[aolszowka]

@Mike-EEE

Nope you were spot on thanks for the catch!

[shederman]

@aolszowka My email address is on my public github profile...

Would you by chance go as far to call them poser kids?

I don't believe I called anyone any such thing. Ever.

That would be you.

I am tired of you continually trying to make this argument about software tools personal. Please edit or resubmit the questions, or send them to me on my private email address.

[Mike-E-angelo]

Because as I stated in my above post your Xaml file is including the xmlns and Visual Studio is performing this required task for you

OK... so here we have our issue. I do not believe XSD is used at any time during a Xaml file schema resolution. But, I am not 100% familiar with intellisense internals and this is getting outside of the scope here and want to keep this on-topic (did I really just say that?!)

This is what is occurring when you hit Ctrl+B in your environment

Right but this does NOT happen in a MSBuild file. Incidentally, if MSBuild switched/supported an Xaml format this would all work as requested with very little effort. :smile:

While there are merits in looking at code this does not help someone new to MSBuild understand the system; a design goal for your proposed improved system if I've understood everything you've said here. I just don't see how it gets you there.

Haha... sounds like a :-1: from @aolszowka here. I think I've done my best here in explaining my position to you. Sounds like I have done a poor job. Maybe some other perspective/conversation will help me get my point across at some later time. :sunglasses:

[RichiCoder1]

Two random ideas I'd like to through out there:

1. Trivially importing props from another format. A lot of the nice-ness around project.json was being able to edit the configuration trivially. Removing the cruft and doing something like:

MyLibrary.csproj

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <Import Project="project.json" Type="application/json "/>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

project.json:

{
    "name": "MyLibrary"
}

With things like references, <ItemGroup><Compile Include="**\*.cs" /></ItemGroup>, namespaces, and such included by default. Project.json would dictate packing, naming, includes/exludes, dependencies, while csproj would actually glue it all together. Easy, humanely-readble and editable configuration. More convention over configuration. Everyone A lot of people win.

1. Make it trivial to shell out to something like .csx or other scripting tools for easy extension. Like it or not, writing task is not simple currently. FAKE, Cake, and psake for cross project and deployment orchestration, msbuild for project glue and configration, and the ability to drop into scripts for extending project builds, all while minimizing the need to interact with the Xml people seem to hate so much.

Let me know if any of this seems wrong or missing something. I know this is still an oversimplification of what would be required. Lot of inspiration from @davkean, especially for (1).

[shederman]

So basically:

Let's remove pretty much everything about MSBuild, except make MSBuild the coordinator

I mean it's a step in the right direction. But why do I need or want MSBuild involved at all then? Why am I spinning up ancient legacy tech, that large number of developers have grown to hate, to build?

What's MSBuild's use case in such a scenario?

project.json is acting essentially as the project file project.json/nuget.json is the references Scripts for project builds

What does MSBuild do exactly?

We run dotnet build It spins up MSBuild Which does nothing other than coordinate a well known list of steps

So, again, what does MSBuild do? And if it does so little, why are we using it?

No, no, how about this:

1. Build on the project.json project system
2. Have dotnet build able to restore, build, test, and pack
3. Allow an extension point to shell out to MSBuild for people who want it
4. Also allow said extension point to shell out to other build systems

Essentially, we have a "basic process" built into the tools, which can be extended by custom builds if required. The only downside I see about that is that it probably keeps commands in the project.json file, which theoretically should be a pure project definition.

"build": "msbuild MyProject.csproj"; // Ta-daa!

OR, my original proposal, have both. If you have a csproj delivered project, build it using MSBuild, and if you have a project.json delivered project, build it using the built in simple tools.

[shederman]

And the syntax I suggested there is only one option.

We could, e.g. run msbuild if there's a project.msbuild file in the dir. There just needs to be something that tells the "default" system to use a "proper" build system.

A lot of the root cause for MSBuild's over involvement in the VS system is that it tries to do everything. It does references, and build, and project definition? Why? Because it's the root of the build system.

It shouldn't be. The root of the build system should build a raw project definition.

MSBuild should be an option for those needing it's power and extensibility.