Essential .NET - Essential MSBuild: A Build Engine Overview for .NET Tooling RRS feed

  • General discussion

  • The project file for .NET Core projects has finally stabilized into an MSBuild file, but simplified and improved over the old version. Mark Michaelis describes the new MSBuild and provides a broad overview of the places where MSBuild is leveraged within the .NET Tooling suite.

    Read this article in the January 2017 issue of MSDN Magazine

    Sunday, January 1, 2017 10:28 PM

All replies

  • A very good article.

    Is there any mention of if/when non-coreclr projects will be able to use the new format? I was hoping that VS2017 would import and upgrade my .NET projects to this format, but for now (RC1) it does not.

    Is an upgrade process possible for .NET 'legacy'?

    Wednesday, January 11, 2017 11:35 PM
  • Nice article. What will happen to project.json in .net core projects? It will dissapear? We have to use .csproj now?

    Thursday, January 12, 2017 11:13 AM
  • In a previous blog post (https://blogs.msdn.microsoft.com/dotnet/2016/12/12/updating-visual-studio-2017-rc-net-core-tooling-improvements/), the PackageReference element in the csproj file was shown to have been simplified such that Version was an XML attribute. eg:

    <PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />

    However, in this post, we see Version being a child element of PackageReference. eg:

    <PackageReference Include="Microsoft.NETCore.App">
    I'm hoping the less verbose version is the one that will actually be used.

    • Edited by Mike Daw Friday, January 13, 2017 6:20 PM changing example xml
    Friday, January 13, 2017 6:19 PM
  • Yeah, this article is all sunny skies and rainbows, but doesn't really speak to the total cluster and community backlash that has occurred from having to switch between different formats and the angst with having to be stuck with a particular format that no one likes (unless you are like me and have had your hands in MSFT code for over a decade).

    There is an outstanding, popular vote which is asking for a serialized-POCO-based solution which would allow developers and teams to use their format (and tooling) of choice.  You can vote for that here:


    By far and away the most popular item in the repo.  Please feel free to upvote and/or join the conversation there.

    Monday, January 16, 2017 6:39 AM
  • Let's be realistic here. 98% of the developers don't care if it's json or csproj.
    The 2% are the early adopters. I can agree it wasn't fair to them to change back to xml files.

    Tuesday, January 17, 2017 2:50 PM
  • LOL @ 98% David... I invite you to check out the twitters and MSDN blog comments (or even the thread I mention above) to see how divisive this issue is.

    Unless you mean 98% of the developers don't even engage in these things, which could also be the case. :)

    • Edited by Mike-E_wins Tuesday, January 17, 2017 2:54 PM
    Tuesday, January 17, 2017 2:53 PM
  • I know people have been going mad over this.

    But yeah, those that don't engage, it's them that make up the 98%. Not you (I've seen your handle before) or me.
    Those at their desk doing their job, not following blog posts or twitter or github, not going to conferences, not waiting for the newest iteration. Don't get me wrong, they are getting work done, like they know how to do it. It's just not in every person's or company's cultures to look at the upcoming technology changes.

    Think Scott Hanselman was about right with 99%, but I hope it's 'only' 98% though. Maybe it has evolved over the years and we might be closer to 90% or 80%... There must be millions of developers. Maybe it's best not everybody has something they need to say :-)


    Thursday, January 19, 2017 10:11 AM
  • Haha yeah hard to find fault in your reasoning, David.  I too have thought about this a bit and it's amazing how at the end of the day how little feedback there is given the scope and breadth of the market here.  The medium used also matters, as well.  For instance, Twitter is ridiculous and there is a whole culture on there.  MSDN blogs (and on here) are mired in tech built in 2000 and not only gives a poor customer-facing experience (and attitude), but turns away potential input because of it.

    But yeah, I guess that makes us l33t. :)  In any case, I still have hope that MSFT will finally realize that data formats are like coding languages.  In much the same way they give developers and organizations CHOICE to develop in C#, VB.NET, and/or F#, MSFT will hopefully finally wisen to the fact that giving the same power to organizations for their data description/persistence mechanism is just as important and deserves the same consideration.

    • Edited by Mike-E_wins Thursday, January 19, 2017 5:11 PM
    Thursday, January 19, 2017 5:11 PM
  • Observing reaction of net developers in my company. I think backing from project.json is a mistake. Improving, wouldn't help. Readability and learning curve are not comparable. Also, Java and node programmers who started to pay close attention to Microsoft stack, reasonably or unreasonably could be spooked

    • Edited by ygizhitsa Tuesday, January 24, 2017 2:46 AM
    Tuesday, January 24, 2017 2:28 AM