In the standup, Damian mentions that maybe the Nuget related stuff will move into something that will be a replacement for the current packages.config. Obviously these decisions are a fair way down the road, I doubt you will get any concrete answers at this point.

And I don't agree that "JSON is hands down simpler to represent those dependencies". There are pros and cons. See this https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

I agree about the change _if_ were moving to nuget.json. that's the only part of project.Json that i thought needed to be dev editable anyway.

@darrelmiller Yaml is probably a even better alternative in terms of verbosity. And you cheated with the comma separated string instead of arrays ;).

@sandorfr It is. However, I suspect one of the reasons for moving back to an XML based project system is because of the existing significant tooling around XML based project systems in the .net ecosystem. My comments are not to try and identify the best format, just to point out that XML isn't intrinsically bad.

Yes and that is the worst news this week. It's like being brought back in time... :( Indeed Xml is not bad, msbuild however... And an msbuild xml base project won't be as slick as you described.

However, I suspect one of the reasons for moving back to an XML based project system is because of the existing significant tooling around XML based project systems in the .net ecosystem.

I just don't get why all the things has been suffixed with "core" to indicate it's a brand new thing if the intention is also to carry the baggage forward like msbuild.

The process has been too painful for more than two years but lots of people were OK because all of new additions and improvements were aligning the ecosystem with other ecosystems and all of them were changes for good reasons. However, suddenly, dark matter enterprise developers started giving feedback behind the closed doors and we are seeing lots of baggage to be carried forward.

There is not many ecosystem out there which has XML based config. In fact, all the new designed ecosystems are embracing other formats (YAML, JSON, etc.). Look at the reaction from all the people on social media, I don't see many people who like this change. However, feedback that has been given privately seems more important to team. That's not a bad thing, I understand the reasons but it's just showing the way the decisions are being processed on this ecosystem.

+1 on worst news of the week. Where was the discussion on this? I can't find anything, just a unilateral decision.

I don't see any community support for this decision, and a lot against (85% to 15% at last count). How did the discussion go, who made the decision, based on what information?

Is this how we're doing things in .NET Core? Compromising quality behind closed doors because we want to support an undisclosed list of legacy tech?

By all means let's do a VS extension that creates a .csproj from a project.json that people who use those old technologies can make use of.

But do not send us back to the nightmare of XML based project files. They were a bad idea when they were introduced, and we've been paying the tax of bad merges and difficult readability for over a decade. It's enough.

I think you are being too pessimistic - and I guess that's mainly because we all got surprised by this. Let them share more info on their plans and then we will see. @DamianEdwards clearly said that they want to keep the good parts of the project.json model.

In my opinion that would be:

• not having to specify each cs-file
• being able to modify the file without having to unload the project
• being able to modify nuget dependencies directly in the file (with IntelliSense)
• being able to replace nuget packages with local source through global.json

In terms of compilation, I just think that it should be possible to compile it without having Visual Studio installed. To me, it doesn't matter if the actual command is "dotnet build" or "msbuild". The important thing is that there should be a way to compile the whole solution, which - by the way - does not yet exist in "dotnet cli" (at least not as far as I know).

If this can be accomplished, I'm ok with whatever syntax they use. XML is not great but JSON clearly has its disadvantages as well.

Edit: I think this doesn't change any of the fundamental (and great) ideas of .NET Core etc.

IMHO, the main problem is that these types of drastic changes just before RTM is not good. If this happen in beta times then may be developers/teams will not become that much surprised. Think about the investments people are doing since last 2 years. Think about current products/libraries/framework depending upon project.json system. Asp.Net is in RC not in preview/alpha/beta, these type of changes break developers/teams trust :(.

IMHO, the main problem is that these types of drastic changes just before RTM is not good.

I thought so too at first but as far as I understand it, this will not result in any changes to your application code. It will only affect your project.json/xproj/csproj files and they said that the change might be automatic - so this will be similar to the good old project migration steps that have already happened many times when you upgraded Visual Studio.

BTW I always thought having a project.json and an xproj file (which contains the default namespace for Visual Studio templates and some output paths, so you have to edit it as well sometimes) was weird.

BTW I always thought having a project.json and an xproj file (which contains the default namespace for Visual Studio templates and some output paths, so you have to edit it as well sometimes) was weird.

Maybe it is weird but they answer to different things project.json is the only file needed to build a .net core project and xproj is related to proprietary tooling a.k.a visual studio. It is very similar with package.json and .idea if you use webstorm to work on your node projects. Just separation of concerns. Visual studio could hide project.json under Properties if they like and offer a merged curated gui experience if they like without mixing everything together.

i've been using this stuff on a mac in VS Code for so long I forgot all about xproj. OTOH, I've really missed debugging and quite a bit more from Visual Studio!

I think you are being too pessimistic - and I guess that's mainly because we all got surprised by this

No, I'm sorry I don't believe I am being too pessimistic. XML is a bad format for any situation where you will be doing code merges, i.e. all software projects. XML was not designed for things like configuration files and project files, and should never have been used for them, .NET just had the bad luck to be built back when everyone thought XML could solve everything.

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

Now, .NET Core is being built when everyone thinks JSON will solve everything. I don't believe JSON is any more a long term solution than XML was, but I do know that it is easier to merge JSON conflicts than XML ones.

I've been finding it a breath of fresh air not dealing with XML rubbish for project files, I've found it easier to read the JSON files, I've found the JSON files easier to work with outside of Visual Studio, and I do not want to go back to XML/MSBuild.

Yes, these are my personal feelings, and yes they are subjective, but based on the comments on Twitter and elsewhere I don't believe they are isolated. To be honest, this decision is making me completely doubt the whole direction of .NET Core, and most especially the way important decisions like this are made.

@DamianEdwards clearly said that they want to keep the good parts of the project.json model.

From my perspective, the best parts of the project.json model are that it's not csproj, not MSBuild, and not XML. Will those "good" parts be kept? Apparently not. After we got suckered into believing they were finally getting turfed, it turns out it was all misdirection. We got told about the new build system, about Gulp and project.json and how things would be different now, and then it turned out it was all a sham and it's crappy old MSBuild back again.

I think the formats JSON and XML are pretty much the same in terms of merging - both have closing tags (although it's just a curly bracket in JSON) which means you have problems with empty/one/many scenarios. Just change an empty JSON array to one with items. I'd argue that JSON even has the additional disadvantage of the ending comma which changes two lines if you add an item to a list.

You would have to move to YAML, etc if you want to avoid that.

IMO the problem with csproj is not with XML but with how Visual Studio treated it and that it contained every cs file. If this gets fixed and if the tooling doesn't randomly change stuff in the file, merging shouldn't be a problem anymore.

However, in terms of readability I also prefer JSON. I was able to write a project.json from scratch - I guess I'll no longer be able to do that with the csproj (csproj requires a random ProjectGuid etc). So we'll definitely need tooling/command line support for this.

My main concern about this whole thing that I haven't heard much about is that the project.json is much more declarative when it comes to references than .csproj project files are. The beauty of the dependencies in the project.json file and why I was looking forward to migrating our codebase to it is that you just say "I need this dependency" and it doesn't matter whether that's a local project or a NuGet package. In our case, this would buy us a lot of flexibility and cool new options. In contrast, currently a reference in a .csproj file is a hard, relative path to a .dll file on disk. Right now, adding an entry into your packages.config in a traditional project doesn't really do anything, you also need to add a reference to a specific .dll from that package to the .csproj file. That's done for you by the NuGet tools inside Visual Studio, but I don't want to use those tools when adding a line of text to a project.json file is a lot simpler.

I recognize that the team wants to keep all functionality provided by the project.json file and expand the features of the .csproj format, but they also talked about keeping project.json around as a file to specify your NuGet packages in. I don't see what that would add compared to the current situation with packages.config where just adding an entry to it is not enough because you still need to add a reference to a .dll in the .csproj as well. If the .csproj file is to become the future, I'd much rather see the Core team go all the way and drop project.json or nuget.json or however it ends up being called _entirely_ and add a more declarative way to add references to the .csproj format. I can live just fine with having to edit an XML file instead of a JSON file (though I certainly prefer JSON) but it would be a real shame to lose the declarative nature of project.json and I don't need two different places where I need to specify my dependencies.

Please give feedback at https://www.surveymonkey.com/r/H6Q88PP

Just to be clear, in reading the Standup notes, it mentions that one option is to have a nuget install --save sort of option (see https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/). While I think that's a good idea, replacing the 'edit .json file with intellisense' with that I think is a bad idea. I think staying in the editor is a good idea for some of us who don't want to switch to a shell to do everything. My preference, personally, is to have both experiences. command-line + UI to add dependencies aren't good enough.

I am a coder, I don't want to leave the editor.

I think this is a horrible decision. You guys said that you want to make .NET Core truly simple, but then you make this change. I don't care how much lipstick you put on MSBuild it's still going to be MSBuild and outsiders are going to look at it and be immediately turned off. It's never going to be a simple hand editable format. Maybe there were some tough technical problems, but it sounds like those were related to trying to make the project system into more than just a simple project system. If people want to do more complex stuff in their builds then they could write some scripts or use msbuild to do that. project.json is a beautifully simple thing and I am really bummed now.

My favorite quote on MSBUILD files?

I recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor.
Ant/Maven was loved and then subsequently hated by a lot of java developers. XML is an extremely verbose syntax to have to deal with.
But the real killer is one of lockin. Yes you can use msbuild to do things with them but the syntax is really designed not for a developer to read/edit them but for an IDE to serialize state to. Just because there is a command line runner doesn't mean the format is developer friendly. As long as you stay in VS you won't really notice. As soon as you leave though its no longer comfortable. csproj files are one thing I wish .Net had taken a different path from java in.

Source

I think it is important to make a distinction between MSBuild and the way Visual Studio currently uses MSBuild. I have been hand editing MSBuild files for years and use them for all of my projects. E.g. https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

The csproj files that Visual Studio creates are pretty nasty, but blaming that on MSBuild is like saying C# is crap because you saw a code generator create ugly code with it once.

@darrelmiller I agree.

Let's move time forward 6 months and see if it's a "told you so" moment or more of a "dodged a bullet".

Following @shawnwildermuth call on his blog I will throw in my own 2 cents:

I don't see why this is such a big deal. I am happy to move back to an XML-based csproj, because:

• Editing JSON manually is NOT more natural/easier than XML. It is actually the opposite IMHO. Every stupid editor gives me XML tag completion, spotting a format error manually is easier and so on. JSON is not easier if I have to write it manually. Saying that brings me to point 2...
• Why is there so much fuss about editing a project file with an editor in the first place? Editing a project file is NOT where I want to spend my time as a developer. This should be a one off thing in the beginning of a new project, but after that should not happen very often IMHO. If I have to edit it with JSON, XML, YAML, TOML or whatever someone fancies at that time is completely irrelevant to me.
• The one thing I would like to avoid is to tighly couple NuGet with ASP.NET. NuGet is great, I love it and I want my ASP.NET to work very well with it, but it is NOT required to run ASP.NET. Yes, I might need to pull the binaries from a NuGet feed to get the features of MVC, etc., but whether I do this via the official NuGet feed, or if I pull the sources, compile it locally and copy paste it into a folder should be a flexibility which remains available to me. I don't want ASP.NET, the csproj or anything else be tightly coupled to those "supporting" 3rd party systems. I want them to allow a great integration, but keep the door open for customization! Therefore I would hope that NuGet packages will not be declared in the .csproj file and that a nuget.json will not be tightly integrated into MSBuild.
  Tight integration behind a well defined interface == GREAT.
  Tight coupling, assuming this is the standard for everyone == BAD.
• Lastly, I want to say that the project.json has very little to do with .NET Core and ASP.NET Core. Core has so much more to offer than a project.json file. Project.json was not a new feature, it was an attempt to re-design something which already existed in a different format. I don't care about that too much, because as a developer I rather focus on the new features and possibilities given by .NET Core to develop a great application in the cloud instead of the boring configuration I have to do once in a while.

I think it is a great move to go back to MSBuild, because as a developer I care more about compatibility and I think this is the key. MSBuild works, and to be fair it works very well for the most part and instead of replacing it with something new, which brings new problems and causes compatibility issues I rather have someone improve the stuff that already works and make it better over time. Everyone thinks they can re-write stuff and make it better, until you realise you only solved a small problem space which was important to you at that time and then later when you want to expand you find yourself re-building the same old thing that you tried to replace in the beginning. Better to improve the things that already work.

This is also why I probably would have preferred to make Mono better and close the gaps instead of implementing a new cross platform runtime, but that's a different discussion.

Final survey results: 100 responses, for a 9 million .NET developer population that's ±10% with 95% confidence.

Did you like the move to project.json?
Yes, it was one of my most anticipated features 19.19%
Yes 39.39%
No 13.13%
No, it was an awful direction to take 16.16%

Are you happy about moving back to MSBuild?
Yes, now I can think about adopting it 9.09%
Yes 16.16%
No 30.30%
No, this makes me question the direction .NET Core is taking 29.29%
Don't Care 15.15%

Do you believe that MSBuild will be improved
Improved? It's already perfect. 1.01%
Yes 63.64%
No 12.12%
It's fundamentally broken, how can it be improved? 20.20%
Don't Care 3.03%

Do you think this decision was made correctly?
Yes, the team took feedback on board and changed direction when they had to 20.41%
Yes 6.12%
No 24.49%
No, the team made unaccountable, closed-door decisions, without involving the community 39.80%
Don't Care 9.18%

How does this decision affect your perception of .NET Core?
Improves it, they're finally coming round to sanity 13.00%
Improves it 11.00%
Worsens it 42.00%
Worsens it, makes me question the whole thing 18.00%
Don't care 16%

100 people did the survey. I did not even know about it until now. Let's look at it again when we have representative numbers, because 100 people is a bad joke at most.

Actually, as indicated 100 people gives you a ±10% margin of error with 95% confidence. What level of confidence would you require in order to see that you're seeing a true reflection? Must we survey all 9 million developers?

Do the 800 votes on UserVoice to extend project.json to the rest of VS not also show the trend?

And if we're going to do a truly representative sample, then maybe Microsoft should do it. Since they've not once asked for input about this decision, even after repeated complaints from numerous directions.

They'll have a much better reach than me doing a private survey. I'd need to upgrade my SurveyMonkey plan to access more than 100 results, at a cost to me, so I can run a survey that Microsoft should have done themselves!

Well if you want to have meaningful numbers then you want to aim for a fair representation of the 9 million developers. If I have 100 Twitter followers, who follow me because we share the same interest and I ask everyone to take the survey then you have 100 people with a very one sided view representing only one particular group of developers.

The justification given in the standup for resurrecting MSBUILD was to make it possible for integration between existing tools and easier for existing projects to make use of .NET core. However, after migrating a rather large project to .NET core, to be honest the project system was the LEAST of my challenges. So using that as the sole justification doesn't seem like a great reason to me. I have also worked for years with the csproj system including manually editing files. That was always painful. The project.json based system is MUCH simpler and much more approachable by all (including newbies). I would think this the goal. And yet now we are taking a step backwards by resurrecting MSBUILD. My personal opinion is that this is a big mistake. I put my vote in to keep project.json.

Actually I have almost no Twitter followers, those are largely followers of .NET Core devs whose Twitter streams I posted on.

And again, surely the correct people to be doing such a survey would be Microsoft? Why is it left to me to be the only one actually asking people what they want?

Why do MS not give a damn what people think?

TBH I did not know that there was a survey up until 30 minutes ago and I did not know that you are doing the survey privately. I agree... if Microsoft has an interest in the developer reaction to this change then they should run such a survey. But maybe they already did their homework and this is why they are making this change. I don't know, but I wouldn't always see things so negatively, because after all these guys are building this stuff for us, so I am sure they have only the best interest for us.

If they had done their homework they would have known that 60% of devs were against this move, and would have communicated and engaged accordingly. They did not, which means they had no idea of the reaction, which means they didn't engage.

I'm a paying customer on enterprise licenses for VS. I saw nothing. I work at four blue chip finservices firms, also paying enterprise customers. They saw nothing. So who exactly did they engage with? I've been asking that question since last night and haven't received any response on it.

I'm seeing things negatively because this is a massive, late breaking change to a fundamental part of the .NET Core story, a part that was communicated to us as being core to the future, and we (perhaps stupidly) took them at their word, and have built a CD/CI pipeline based on this tech that is now utterly worthless. I'm also seeing it negatively because in a full day of asking for details on the decision making there's been utter radio silence.

It sounds, from what I've heard, that they've thrown the users under the bus to help the tool makers. If so, please can they collect my VS license fees from the tool makers, and not from me.

@shederman While I agree with the results of your survey, its questions are obviously slanted in the preferred direction of staying w/ json format, and that doesn't really make it a good survey. I took it for fun, and I wouldn't take its results seriously (sorry). I do wonder why we can't have both - make it optional one way or the other, because I am no fan of msbuild or that other stuff. I love json, it's my friend.

I agree with you that it's not an ideal survey. I created it in the space of 5 minutes. the point is: why am I creating it?

Why isn't Microsoft interested in finding out what people think?

I only expected about 30 responses, and I hoped it would be enough to convince them to reopen the discussion, share their thinking openly and engage with us properly rather than riding rough shod over opinion.

It's now at 138 responses, but there is still no sign of Microsoft even considering that maybe their decision was a bad one. Just very vague hand waving explanations not backed up by the facts.

All I want is a proper engagement on this decision. Not major decisions made behind closed doors based on secret information and feedback. This should be made openly and with transparency, a word that has been singularly missing in this process.

Oh guys come on. Microsoft own the framework and lets allow him to do what he wanna. But think for a moment, peoples are working on this since March-April 2014 and just before 1 month of release making these type of dramatic change is ridiculous. It breaks developers trust. It waste peoples time. No need to make open source framework if you can't trust the community. Go and make it close source immediately so no one will bother you when you do these type of changes in the dark rooms.

I request Microsoft apologist and sympathetic (MVPs or Community Members) please be realistic in this time.

@shederman

If they had done their homework they would have known that 60% of devs were against this move,

It would surprise me if more than 20% of the devs in the .net ecosystem even know of the existence of project.json. We forget sometimes that we live in a bit of a developer bubble, riding on the forefront of new tech developments.

I believe much of the appeal of project.json is its simplicity. However, if you have been following along with it's development since it was first introduced on the ASP Net Insiders day 3 years ago, it has started to accumulate more complexity as it tries to support more use-cases. In order to support the entire .net eco-system I fear much of the beloved simplicity would be lost.

This is not to say project.json doesn't bring in some awesome new features, and I believe making the project format more human accessible is a good thing. However, I think bringing that goodness to MSBuild is more achievable and will benefit far more people sooner than trying to bring project.json everywhere.

It would surprise me if more than 20% of the devs in the .net ecosystem even know of the existence of project.json.

I would bet less than 20% devs in .net eco knows about MVC and Web Api. More than 70 peoples are using WebForms, WCF, WebService. Again I request Microsoft apologist and sympathetic please be realistic

@shederman Your report of any confidence from the results of your survey is probably incorrect for the population of .NET developers at large, and it might not even be a good representative sample of ... "those are largely followers of .NET Core devs whose Twitter streams I posted on." Your sample is not a random sample, which is absolutely required for you to state any such confidence interval as you imply for the population as a whole. Even if it were a random sample of .NET developers, you cannot report 95% confidence in each answer because you failed to adjust for simultaneous inference.

No useful statistical conclusions can be drawn based on your survey for the population as a whole. However, I am glad you did the survey. You present many excellent points. I think the results do indicate that many people are either upset or concerned about the change. However, please don't publish false statistical conclusions ... passing off numbers that are virtually meaningless and making such outrageous remarks as "they would have known that 60% of devs were against this move."

Then what is the point in changing anything if we're going to bother 70%+ of the market base? Let's stay exactly where we and keep on doing incremental evolution. If it ain't broken don't fix it, right?

I know that project.json has accumulated complexity. I 100% agree on that point. Was the solution to merge back to csproj? I told people before, I'm completely behind Microsoft for making things right rather than shipping in a hurry. The move to csproj looks rushed.

Why do this after RC2? Where did this come from? Does the Xamarin acquisition had anything to do in this? Was it the dotnet-cli integration? Was it a big client? Who knows...

I could explain to the masses that RC1 -> RC2 was for the best. Unified with the dotnet cli. But the project.json change? I have nothing to say to explain it. Just that I don't know. People are confused and I have no compeling arguments for them.

Why do this after RC2? Where did this come from? Does the Xamarin acquisition had anything to do in this? Was it the dotnet-cli integration? Was it a big client? Who knows...

This is the point thought. We don't know the full story behind the move to csproj. Now instead of leaning back, relaxing and watching and understanding why this is happening everyone is cursing Microsoft and assuming the worst. This doesn't make any sense. These guys are building this stuff for us and us only. They definitely don't make such changes because of 1 big customer, because 1 big customer is worthless if you risk to loose your entire community. The Microsoft .NET eco system is HUUUUUUGE and making .NET Core fit nicely into it is obviously a complex task, so I would suggest everyone chill out a bit and assume that these guys have some clever people behind it, making the right decisions so that we can benefit the most from it - long term. I am out from here, because all this negative premature speculation is boring me.

@darrelmiller Sorry, when I say 60%, I do mean 60% of those who responded to the survey.

@GuardRex You're absolutely right. The only organisation that can get us proper results is MS, and they don't appear to care.

My survey was simply meant to gauge a vague level of support, not to provide a statistically significant sample. I believe I've shown that there is enough unhappiness to open up this decision, but it appears Microsoft do not agree, well if their radio silence is any indication.

Here's the question: what exactly would be required for MS to admit they perhaps made a mistake? What would it take to get them to reopen the discussion? Because at this point in time it seems the answer is "we don't care about your point of view, our decision stands, and we're not going to share the reasons"

I would suggest everyone chill out a bit and assume that these guys have some clever people behind it, making the right decisions so that we can benefit the most from it - long term

Thats what I said make it close source because clever people behind it and they are always right and the open source community is fool.

@shederman "not to provide a statistically significant sample" ... that's fine, but I wish you would just let the survey stand on its own merits and remove this line ...

Final survey results: 100 responses, for a 9 million .NET developer population that's ±10% with 95% confidence.

That's the part that gets really dicey. It might be accurate that 60% of .NET devs hate or dislike this change; however, you can't show it with that sample. Let's just say, yeah, a lot of devs have a major concern about the change and the way it was handled. That's clear, and the survey really highlights that point well.

@abcplex: Open source does not mean you have to jump every time 16 people open an issue on GitHub and scream jump.

@MaximRouiller The Standup Notes do a pretty good job of explaining the motivation for the changes. And the reality, as I read it, is that xproj is getting replaced by csproj and project.json is likely going to be renamed nuget.json and _some_ stuff will be moved out of project.json.

And from comments made in the standup, this was a pretty recent decision, the community has been told almost immediately, project.json is not going anywhere until after RTM, so changes could happen again.

To me, this seems like the most inclusive and transparent process that could possibly have happened.

@darrelmiller That, I'll have to agree with you. Pretty transparent.

If they wanted feedback, I think they got it. In any case, there's no fighting it. The people spoke. Microsoft listened. Let's see if it's something they can do something about or their hands are tied.

Only time will tell us now.

I don't think the problem was with their transparency. They have done an awesome job of being transparent. I think the problem is that they are making big breaking decisions without knowing what the community thinks about this. I know it's impossible to design by committee, but maybe they should have documented the pros and cons list that they went over and presented it to the community for something as fundamental as this change. Hopefully they will post that type of info soon, but, even so, it sounds like the decision has already been made.

This affects early adopters more than anyone else.

JSON reads nice, but only when it's simple. </system> is easier to understand than ]} in my opinion.

Most reasonable comments on here echo my own thoughts regarding unloading/loading of projects and dependency management not needing the verbosity inherent in XML.

Should it really be a discussion about JSON vs. XML? Doesn't really matter IMHO
(sure, personally i like JSON more than XML but this is not important)

What I really like about ASP.NET Core is, that it is pretty open and independent from Visual Studio and any other IDE. If this is still given, I've no problem with this decision.

There's quite a lot of toxic discussion going on in this issue, which I feel is causing a lot of people to lose sight. The general argument seems to be "MSBuild is bad!" but not enough understanding of what is good / bad about both approaches is being made.

For everyone stating that this is a "step backwards", be aware that although it's going back to "csproj", it won't be the _same_ as the csproj files we've had for years. For one, they have stated clearly that you won't see a list of files in the "new" csproj format. The main benefit and main reason most people have liked the project.json format is down to not having this list of files.

Right away that's an immediate difference. Take a look at the xproj today and you'll pretty much have an idea of what to expect from the "new" csproj. It'll be a little bit bigger, but only because it's going to have a few extra properties taken from project.json. The real discussion isn't and shouldn't be about "how bad MSBuild is" but what you want to see in the new csproj and what you want left in a .json file.

@dustinmoris you are unfair, I think community welcomed most changes but this one. This one is taking us backward, and they are already talking about the how they will do it without any insight about the why. They make it sound like the decision is final so there is no place for the community to maybe come up with a better proposal.

And yes we do edit project files directly and we were doing it painfully before project.json. Msbuild is all about tribal knowledge and makes mastering it a bit hard.

And the "it will ease migration from .net 4.5 to .net core" seems a bit dishonest. This is definitely not the pain point...

it won't be the same as the csproj files we've had for years.

Will it be XML? Yeah, I thought so.

The main benefit and main reason most people have liked the project.json format is down to not having this list of files.

Based on what information do you say this? I mean, not having the list of files is major plus, but by no means the only one for me.

Take a look at the xproj today and you'll pretty much have an idea of what to expect from the "new" csproj

I don't have xproj's today. Why would I need such a thing?

The real discussion isn't and shouldn't be about "how bad MSBuild is"

Why _shouldn't_ that be the discussion? Turfing MSBuild was a major plus point for my adoption of .NET Core. 20% of the respondents on my (apparently) unscientific, echo chamber, biased survey agree that it's fundamentally broken.

@shederman your response is exactly the kind of toxic discussion I am referring to. You're just making generic claims (like "MSBuild is bad!") but you're not backing them up with any kind of constructive discussion.

Will it be XML? Yeah, I thought so.

Yes. And? If your problem is that you don't like _XML_, then fair enough. If you think JSON is superior to XML then go ahead and reel off your reasons why but that's nothing to do with the _project structure_ and everything to do with syntax. Unfortunately for you, both XML and JSON have their place in the world, there are distinct pros and cons to both and there's never going to be a definitive "right" answer as to which is better. Again, if I were you I would concentrate on what the differences in _project structure_ will be with the move.

Based on what information do you say this? I mean, not having the list of files is major plus, but by no means the only one for me.

I never claimed it was the only benefit, I simply said that it was by far the _main_ benefit. Look at any discussion about the project.json format going back months and the first thing people talk about is how much smaller and simpler it is. That's not because JSON is syntactically cleaner, it's down to the removal of the list of project files. The biggest plus people mention is that it merges well and it merges well because it doesn't list a bunch of file references in it.

I don't have xproj's today. Why would I need such a thing?

This entire discussion is about the newer project file format, if you're not willing to compare the current landscape then your opinion is going to be an uninformed one.

Why shouldn't that be the discussion? Turfing MSBuild was a major plus point for my adoption of .NET Core. 20% of the respondents on my (apparently) unscientific, echo chamber, biased survey agree that it's fundamentally broken.

Because you're not actually discussing _MSBuild_, you're discussing the way Visual Studio has historically handled MSBuild projects - which Microsoft themselves have admitted is poor. MSBuild actually supports nearly everything required already - including not having to list every single file in a project.

More to the point, all you have done so far in this discussion is scream and shout that you don't like XML, but I've yet to see you bring any real arguments for or against beyond "It just doesn't merge as well", which as I've stated numerous times now is generally down to the amount of files listed in an "old" csproj. If you'd bothered to look at the xproj format, you'd see it's quite small and Daniel said during the standup that the "new" csproj format would be about the same size as the current project.json file - so again, what's the problem? You make bold claims, but you don't back them up at all.

@neoKushan you should soon get some sort of award from Microsoft by defending them for no good reason. Come to real point that this is worst decision made in back doors. I recommend of making the asp net close source again and allow Microsoft and their supporters like u to decide what then wanna without asking open source community members

@abcplex Are you going to contribute anything to the conversation other than name-calling and finger-pointing?

So far you've done nothing but complain about the change without listing a single reason what your actual problem with it is.

@neoKushan the biggest point is that its not a time for this type of change, just a month ago to RTM. Making this change on this time does not make any sense.

@abcplex The change isn't happening at RTM. It's going to be a gradual, post-RTM change. All that happens at RTM is your xproj gets renamed to csproj - literally nothing else changes and changes will be made in stages, with the tools migrating your changes for you.

Agree that the JSON vs XML (vs XAML, as on the Standup Blog Post some people are asking for that) is a distraction from what should be the merits of having any kind of backwards compatibility with the previous tooling.

And I would argue that this is a highly misguided way of thinking. Like it or not, csproj and MSBuild follow in the tradition of ant, which is about instructing the toolchain how to build a project, rather than defining it. These are very different things, but this heritage seems to give the project "definition" power, because now we can apply logic to it, and so on. What that does is make things incredibly complicated.

With the old world, on numerous occasions I have seen project files broken simply because a line that "needed to be at the bottom" was moved up, or someone messed with an environment variable and suddenly we were pulling in the wrong .targets file. The very notion that a First-Level element (child-of-root) is order-dependent in a declarative syntax is utterly broken. That is the land of MSBuild and csproj. This is the legacy we are bringing back here. Now to make sense of a csproj one has to "run" it, and run it exactly as MSBuild would. Yes, MSBuild is open-source, but that is not actually fixing anything. It still introduces a single, forced dependency. It still relies on magic targets files that sit... somewhere.

A project file should have several qualities that make it agnostic to the shape of the toolchain that a given shop decides to use:

• It should be human editable/readable
• It should allow for comments
• It should be declarative
• It should be self-contained
• It should be designed to reduce merge conflicts / simplify merging, if possible
• It should be fully documentable (with self-containment principle applying to the documentation)
• It should be tool-independent

And the "it will ease migration from .net 4.5 to .net core" seems a bit dishonest. This is definitely not the pain point...

Agreed 100%. Let me be clear what the challenges for us have been: the only difficulties so far with migrating codebases has been loss of certain .NET class libraries (looking at you System.Drawing), reticence on the part of Microsoft teams in supporting .NET core (looking at you DocumentDB) and the standard breaking changes that can be expected between major versions.

At no point was project.json a problem. In fact, that one was of the benefits. Ditto being able to dump MSBuild to an invisible detail that magically happens when Ctrl+Shift+B.

@neoKushan

1. I don't like XML. It's a bad format for project and configuration files. It was a bad idea when it was introduced during the "XML for everything" phase, and it's a bad idea now.
2. I find that JSON files merge much better than XML files. I accept that this is an opinion, but it is mine, and is based on my experiences.
3. I'm using vscode that does not need and does not use xproj files. _That_ is my current landscape, and I don't want or need an xproj file that means nothing to me.
4. No, I'm discussing MSBuild. I've done plenty of things with MSBuild and Team Build. They have never been fun, and never been easy, and have always involved wrestling with the pig in the mud. I _hate_ MSBuild, and I am most certainly not alone.
5. MSBuild makes even simple tasks difficult. I suggest you look at alternatives, and not be blinkered by MSBuild. Especially, look at the way gulp and sbt work.

@shederman

I don't like XML. It's a bad format for project and configuration files. It was a bad idea when it was introduced during the "XML for everything" phase, and it's a bad idea now.

None of this explains _why_ it's a bad idea.

I find that JSON files merge much better than XML files. I accept that this is an opinion, but it is mine, and is based on my experiences.

I have had nightmare .json merges and nightmare .xml merges, I am not particularly endeared to either when it comes to merging. In my experience, the chances of a problematic merge increase with the _size_ of the file, regardless of the format.

I'm using vscode that does not need and does not use xproj files. That is my current landscape, and I don't want or need an xproj file that means nothing to me.

That doesn't mean you can't go and look at the current xproj file to get an idea of what it is. By not doing so, you're doing the equivelant of sticking your fingers in your ears, closing your eyes and saying "La la la".
To put it another way, you can be upset at the fact that a change is happening and moan about it, achieving nothing, or you can take part in the actual conversation and help direct the outcome of this.

For example, one thing that's still undecided is if the nuget dependencies will become part of the csproj, or if that will become nuget.json - there's your preference right there. Once you have your lists of dependencies in a .json file, what's left to go in the csproj? How often will that change? How difficult will _that_ be to merge?

I personally would rather that it was all contained in a single project file, but I can see the appeal and benefits of separating nuget from the project itself. There's pros and cons to both and perhaps the best solution is to allow for both, have a csproj with a list of dependencies but also let you point to a .json file with your dependencies instead. Best of both worlds and everyone wins, at the expense of some added complexity to MSbuild itself.

No, I'm discussing MSBuild. I've done plenty of things with MSBuild and Team Build. They have never been fun, and never been easy, and have always involved wrestling with the pig in the mud. I hate MSBuild, and I am most certainly not alone.

Having had to deal with TFS's XAML based build definitions, I can at least agree with you on (some of) this one.

MSBuild makes even simple tasks difficult. I suggest you look at alternatives, and not be blinkered by MSBuild. Especially, look at the way gulp and sbt work.

Then I suggest you stop throwing your toys out of the pram and actively take part in the discussion of what the "new" project structure should _actually_ look like. Imagine a future where you have to deal with an XML based project file, what would you want that project file to actually look like?

Imagine a future where you have to deal with an XML based project file

Um. Okay, so I must imagine a future that I don't want and explain to you how it'd work? Um, no I don't think so. How about we rather look at some modern, more innovative build systems. you know, ones that left XML back in the distant past.

How about:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

Or maybe

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

Oh yeah, that xproj you linked to is so much better. Nice and clear and concise. And expressive, don't forget expressive. What's that ProjectGuid for? And I love the 90 characters to set the tool version. And the DnxInvisibleContent? That's useful for my build system to know? Which files not to show in the IDE I'm not running?

I suggest you stop throwing your toys out of the pram

Don't wanna :-)

Nah, I'm done. Had a long chat to to Immo, and I'm over fighting this battle. Everyone has their partial view and no-one wants to listen to the outrageous concept that their way may not be perfect for everyone.

[Edited to remove petulance]

@shederman: you show here build definition files; I want to get away from build definitions as a project definition. There is space for defining the static details about a project/artifact-to-be-generated independent of the instructions for how to generate it. That it conflates the two is one of the major problems in using MSBuild files as project files.

I want to be able to specify just the information needed to describe the artifact(s)-to-be-generated and the dependencies and toolchain to be used, and the layout of various elements that make up the project on disk. Everything else should be separate. If you want to use MSBuild under the hood, go right ahead. Ditto if you prefer gulp, or babel or what-have-you. To me that is what project.json was set up to do. (I was not a fan of the ability to define commands there, though)

Yeah, that makes sense. That was one of the things I liked about project.json. It defined the "what", not the "how". By putting too many things in one file we make the file too complex, especially if our IDE is stupid. And that stuff isn't needed for editors and simple IDE's.

From a low-ceremony UI like VS Code there isn't much need for a project system. It's all build. A lot of it is declarative, saying what should be built and metadata. Some may be imperative, saying what steps should be performed.

Yeah, MSBuilds biggest issue is it tries to do it all in one system.

I guess what I'm not grasping is this: show me some use cases that are improved by using MSBuild as the project system as opposed to just making project.json work. I don't see it. Maybe my use cases are too simple, so show me some.

@shederman The standup notes mention needing to be able to share source files across projects

So...this is an Open Source project, and I know that Microsoft is "the powers that be" but if this is so important to people, then - and I get that I'm asking an ignorant question here - how much time/effort/energy would need to be expended to allow .NET Core to continue to use project.json as an alternative to MSBuild? If enough people contribute, and the code is good enough, then why wouldn't MS accept it into this project? Part of the beauty (and downfall) of Open Source is the threat of forking the code if the primary maintainer(s) refuse too much of what is offered by others. Part of the point of the code being Open Source isn't just to look at, but to modify and improve.

My personal take on the change is that it does have to do with Xamarin, in that it is about future plans. Also, in the recent stand-ups I believe I heard them say they want building console apps to be a first class citizen. Remember that originally, the new .NET (ASP.NET 5 + DNX) was focused on building web apps, now it is about more. All of this has occurred relatively recently, the .NET and ASP.NET teams merged, and also the Xamarin purchase. They came to the conclusion that they need a better project system to support these multiple scenarios (and new future scenarios which I won't speculate about here) , and they also want to ship .NET Core soon. What to do? Completely ignore the pre-existing MSBuild that can already handle what is required and start from scratch? Sorry, I know the path I would choose.

A good bit of the concern seems to be around merging BUT if the project file does not contain the names of the files in the project, and if the dependencies are pushed into a separate config file the merge issue should disappear as project files should then change relatively infrequently.

Just my opinion

The merge issue is only one issue. Getting away from MSBuild is another. One crazy outcome of this scenario is that they're now going to spend time and effort porting MSBuild to Linux and OSX! Imagine that.

I get their reasons, but their reasons don't work for me at all, and don't work for a lot of people. We made investments based on firm assurances about the direction they were taking, and they've gone back on it with zero accountability, and nothing more than an indication that maybe they should have _communicated_ the decision better. They're making a decision on project.json based on edge cases that MSBuild supports, and how hard it would be to support those edge cases. Well, that means it'll _never_ stop being used, because nobody in their right mind would support all those edge cases. Certainly nobody doing ASP.NET projects needs those edge cases.

Forking is a possibility, but given how big and integrated everything is, it's a daunting prospect to consider even learning the relevant code. The reality is that this isn't really an Open Source Project, it's a Microsoft project, and they've made a corporate decision without our input, and we must just suck it up and accept it. It's been made clear to me that there's basically no possibility that they'd _ever_ reconsider, no matter what opposition there was.

So, it's either we spend the effort and fork the project.json build system, or we switch to another build system (FAKE?), or you suck it up, or you use another platform. I believe I've enumerated all the choices there.

@shederman MSBuild has been open source since early 2015, and the builds are passing on OSX/Ubuntu, so I don't think its as much work as you might think to port (https://github.com/Microsoft/msbuild), browsing the repo it looks like OSX was building OK back in March for example.

Oh dear. I'm concerned about whether we _should_ do this, and they've gone off and done it...

Feel a little like someone watching Frankensteins Monster hurtle off into the distance. Interested, intrigued, concerned, and more than a little disgusted :-)

@darrelmiller The standup notes mention needing to be able to share source files across projects

Really? People still do that? I mean I used to do it for AssemblyInfo.cs, and back in the Dark Ages, we'd put our Strong Name key in a shared source file.

Okay, that is a use case, but now I really do want to hear a use case for the use case. Intrigued.

@shederman

Um. Okay, so I must imagine a future that I don't want and explain to you how it'd work? Um, no I don't think so

All you have to do is accept XML instead of JSON, to see what the benefits could be, but you're not willing to play that game because all you want to do is talk about how bad XML is without actually stating why.

Oh dear. I'm concerned about whether we should do this, and they've gone off and done it...

They've been "going off and doing it" for literally _years_ now. They talked about open-sourcing .net years ago, they gave roadmaps and made it clear that it was about running on any platform eventually, for any use-case.

You're pretty upset by this change and I suspect the majority of people upset by the change are all web developers, but that's only a small part of the .net ecosystem, there's a huge ecosystem of service, mobile and cloud developers that have huge libraries of code they want to be able port over to .net core. Like it or not, project.json just doesn't currently work for all those models. You say "make it work" but you're just going to end up with another messy project file, except one that doesn't have obvious and clearly defined structure and - worse still - no comments. That last point is reason enough to rethink project.json.

Oh yeah, that xproj you linked to is so much better. Nice and clear and concise. And expressive, don't forget expressive.

At least you've finally looked at it. It only took what, 72 comments in this issue before you even bothered? I keep telling you this, but you're not getting it: Instead of complaining about how terrible MSBuild is, talk about why it's terrible.

The merge issue is only one issue. Getting away from MSBuild is another.

Why is this even an issue? You hate MSBuild, we get that, but what is it you hate about MSBuild aside from the fact that it _dares_ to use XML?

One crazy outcome of this scenario is that they're now going to spend time and effort porting MSBuild to Linux and OSX! Imagine that.

You're right! That's going to be awful, being able to develop any kind of .net app on any platform you want, using any IDE you want. Think of the children!
How dare Microsoft spend time open-sourcing their work and porting their tools to other platforms instead of investing in their own closed-source tech.

I get their reasons, but their reasons don't work for me at all, and don't work for a lot of people.

But maybe they work for a lot more people than you?

We made investments based on firm assurances about the direction they were taking, and they've gone back on it with zero accountability, and nothing more than an indication that maybe they should have communicated the decision better.

What _direction_ are you referring to? The goal has always been .net everywhere, "Any developer, any app, any platform" is the mantra of the day and there's absolutely nothing about this change that affects that. They've stated clearly that their goals are to keep the project file small, simple, human readable and human editable without an IDE. Nothing is being taken away from you. You might have to deal with a bit of XML, big whoop, if that means .net is a first-class experience for mobile, cloud and web, then it's well worth it.

They're making a decision on project.json based on edge cases that MSBuild supports

This is far beyond _edge_ cases, it's ludicrous to even suggest that project.json is almost perfect.

Certainly nobody doing ASP.NET projects needs those edge cases.

I suppose this is the crux of the issue: You don't care about anyone other than yourself, an asp.net developer. Fair enough, but again I'd say to you: Accept that other developers matter and instead of just throwing your arms up, work towards making it the best system it can be. That doesn't mean making up arbitrary syntax for a completely different markup, it means accepting that the picture is bigger than just you and working with others to make it great for everyone.
Like I keep saying, if nuget.json listed all your dependencies, what's left? What's the problem with defining some fairly static fields in named elements of XML?

The reality is that this isn't really an Open Source Project

As others have said, being open source doesn't mean bending over backwards to a few complainers. They accept pull requests, go write something better.

given how big and integrated everything is, it's a daunting prospect to consider even learning the relevant code.

Okay, so I'm basically reading this as "I don't understand the bigger picture and I don't want to understand the bigger picture, however I'll still complain because it affects my little bubble with a complete disregard for the implications my bubble has on others".

So, it's either we spend the effort and fork the project.json build system, or we switch to another build system (FAKE?), or you suck it up, or you use another platform. I believe I've enumerated all the choices there.

Or...and I mean this is just a crazy, out-of-the-box thought, but you could try actually contributing something constructive to the conversation.

Getting back on topic....

I have given it more thought and I'm now leaning towards having project.json become nuget.json, keeping dependency management much the way it is now. It works well now, the intellisense is already in there and it's consistent with things like gulp and npm.

Let the csproj simply define the static parts.

However, the downside to this approach that I can see is that I'm not sure how well that would work when targeting multiple frameworks, I don't really feel that it makes sense to put that in nuget.json but nuget.json is still going to have to know about it.

project.json is not just a json file.
csproj is not just an XML file.

IMHO many people, like me, were excited to see Microsoft, more precisely the Asp.Net team,
freeing themselves from very old legacy code/concepts/systems/tools/appearances/...

This gave us 'hope'!

I develop Asp.Net since the very first preview bits. I mostly love to work with it. But after 15 years,
the 'old' stuff, like XML, feels really, really heavy and outdated. Perception IS important.

Without XML and at least using JSON instead, my 'developer happiness' is much greater.
I can work with things, the rest of the world has decided to use. My IDE facvors those things over legacy formats.
I do no longer have to pay 'The Angle Bracket Tax'.

Removing project.json is not a big deal, but doing it behind closed doors almost at the last moment kills that 'hope' instantly.

Suddenly this does not feel like an open source project any longer.

fyi: "Asp.Net Core" has many fantastic features. I mostly love it.
The Asp.Net team is great and I couldn't be prouder to be an Asp.Net developer.

But I am hurt. Maybe I am not the only one.

Just my 2 cents.

I think we can pretty much all agree that msbuild (especially how VS uses it) isn't perfect, and while I was excited about project.json it was more about MS fixing a lot of my pain points and to be honest as long as they do I probably won't care that much about how they did it.

• csproj merges don't work that well, I find myself needing to manually fix a broken merge every other week. Removing the list of files from the csproj would help a lot here.
• NuGet references and Project references don't always line up, again could be due to broken merges. Either way it's annoying to diagnose and correct.
• Occasionally I need to plug into the build process (not sure how that was meant to work in project.json) but the whole needing to unload/load makes the debugging of the build script a painful process.

If they find a way to fix those 3 items then i probably wouldn't complain all that much about csproj files.

@neoKushan

all you want to do is talk about how bad XML is without actually stating why

Not entirely fair, I also want to talk about how MSBuild is bad :-)

I'm sure I actually _have_ said why I don't like XML for build files, but let me give it a stab again. XML is verbose, it is ugly, it is better for tooling than for hand editing, and I don't enjoy the experience merging it. It was used for MSBuild, because back then the industry thought XML could be used for everything. We've moved on since then. Well, in some places.

worse still - no comments

I believe several people have offered alternatives here. HJson is just one option. Yay! We don't have to rethink it after all ;-)

You're pretty upset by this change

To be fair, I'm mostly upset by how this change was made in a closed room without considering or engaging with the community that had taken the previous, very firm support for project.json at face value. Boy, won't make THAT mistake again!

Don't get me wrong, don't like XML, don't like MSBuild. But hate being told to adopt something I really love and then getting told at the last minute that it's being taken away. Don't move my cheese!

I suspect the majority of people upset by the change are all web developers

Umm, yes, that would be because they're the only developers you offered project.json to. In other news, Swift developers also aren't upset about the decision. I mean think what you're saying here:

1. Only web devs got this new feature
2. Many of them were really upset when we took it away
3. No one else got to use it
4. The people who didn't use it aren't upset that it was taken away
   ergo all other devs wouldn't want it.

I think you need to have a look at the quality of your thinking, and that's what I tried to interrogate for quite some time, and got nowhere. The lack of information on the thinking, and the fact that the relevant parties have clammed up, indicates to me that the thinking may have been suspect.

And what do you mean by "web developers"? You're thinking some little website for a small company? How about a stack of microservices, supporting an asset management business with tens of billions of dollars under management. Sure, there's a website there too. But that's about 10% of the system. Oh, and yes, it is actually targeted to cloud too, so maybe we're actually talking "cloud developers".

It sounds like you don't even understand how the technology you're making rash decisions on is being used, or by whom.

what is it you hate about MSBuild aside from the fact that it dares to use XML

It' overly complicated
It's an impedance mismatch, shoving inference based logic into situations where people are primarily dealing with imperative or declarative logic.
My God man, have you actually _looked_ at the MSBuild files? Okay, sorry, you said aside from using XML ;-)
The way that properties and items is declared is counter-intuitive for anyone who doesn't use it regularly
It's used as a one size fits all tool that tries to do tasks that should be done in scripts. Hammer, nails.
In a large number of cases, everything it does in a large file could be expressed in 3 lines of script at most
The VS rubbish that gets spewed into it. I hear that's going to be fixed. Waiting with some trepidation to see if that gets cut too. As mentioned above, I'm a bit gunshy about promises now.

What is it you love so much? And most importantly, are you willing to accept that others may not share your views? If so, can you admit that "one size fits all" might not be the right approach?

What direction are you referring to

project.json is the basis of our new project approach is what was communicated. We invested real money and time and pain on the basis of that commitment.

But maybe they work for a lot more people than you?

Maybe they do indeed. But if so, where is the evidence of that? I've tried to interrogate the thinking and decision making and evidence that was used in this, and I get nothing from anyone. For all the evidence that's been provided you could have shaken a Magic 8-ball for all we know.

No one knows how many think one way or another. I'm actually the only one that I know that actually tried to find out.

You don't care about anyone other than yourself, an asp.net developer

Not very nice. What I'm actually saying is that the assertion is that the new direction works for all use cases, and I'm sticking up my hand and saying it doesn't work for me. You're the one riding rough shod over all opposition. I'm the one asking people what they think, MS are not.

At no point have I said "get rid of MSBuild entirely, and enforce my build process on all other devs". You're the one saying "get rid of project.json entirely, and enforce MSBuild on all devs". We had two build systems in all the previews, and we were happy. The web devs were happy and the non-web devs were happy.

We can discuss how feasible that is, and maybe it's not, but we don't know, because we were never consulted or engaged with.

You really do love your argument of the excluded middle.

They accept pull requests

Really? If we issued a pull request that left a non MSBuild based build tool in the main tooling functionality, that read only project.json, you'd include it in the framework? Really?

Okay, so I'm basically reading this as...

Wow you read a lot into that. Gosh if I read like you, I'd never finish a book. And it would be quite different to what the author wrote.

Try rather, "I don't fully understand the bigger picture and I'm considering the effort and time that would be involved in doing this. It would be much better if we had the assistance of the existing devs in delivering what a significant fraction of their community wants, but I guess if they don't care what their users want we may have to go that route."

Dammit! I read like you! Except it does actually fit the original text a bit better than your somewhat hysterical interpretations.

you could try actually contributing something constructive to the conversation.

Well I thought I was being constructive actually. After I got over the initial shock I tried to find out what the basis of this decision was. I tried to find out what the decision making process was. I tried to interrogate the quality of the thinking that lay behind it. When I was told the majority of developers wanted this, but no evidence was provided to back up this assertion, I actually asked them, which _no one_ on the team had done BTW.

What did I get? Obstruction, insults, and evasions. So tell me, why do you consider it unconstructive to ask if someone making a major decision affecting millions did their homework? And do you consider it constructive or suspicious when said people refuse to show the homework book?

I mean, realistically, these are the likely scenarios:
1) You made the decision based on a full set of feedback and information, and the decision is truly by far the best option to move forward on. If so, I'd shut up, I promise. I find this situation to be fairly unlikely due to the level of opposition you've received, and the fact that you're hiding the evidence and the decision making.
2) You made the decision based on partial views, but the best you had at the time. I'd say the correct response there would be to reopen the decision and solicit the views you left out. I find this the most likely situation.
3) You made the decision badly or based on bad information. In which case, again, you should reopen the decision and solicit the community. I really don't think this is the situation at all, because, much as you may not believe me, I do respect the DotNetCore devs immensely. All of them.

And you know what, if you reopen the decision, solicit the views, and the decision comes down the same way as it has, then what's the harm? And if, after soliciting the views, you realise that some of your decision making was flawed, and you correct it, isn't that actually better?

Wow, seriously. Can we end this?

Simple question: are you going to take the opposition on board and relook at the decision based upon the new information?

Or are you going to carry on just implying that people who disagree with you are crazy, stupid, unskilled, _uninformed_, or otherwise incapable of holding an informed, valid opinion?

Suggestion: Microsoft fork to support msbuild csproj legacy customers. #carryOnAsNormal

I am also a long-time .Net developer, was working with previews of 1.0 before marketing even invented the .Net name. Without getting too lost in the weeds, here is my two cents.

I could go the rest of my life without ever seeing another xml config file and be perfectly happy.

I don't want xml config. Anywhere. Ever.

I don't care if the team fixes every single painpoint of csproj; if it's still an xml config file when you are done, then I'm not interested. You may as well go just keep the .net 4.5 project system.

As for MSBuild... MSBuild can go die in a f'n fire.

I get that it's powerful, and a lot of tooling exists around it, but outside of MS, only seriously deep experts on MSBuild actually know what it does or how it works. Every time I have to plug any customization into the build process, I end up loosing 3 to 5 days of my professional life. I can rarely get anything, even trivial stuff like just including an empty folder in the output, to work right in VS, VS publishing, and my CI server all at the same time.

I get it... if you don't have time to build a good replacement for MSBuild for the asp.net core 1.0 timeframe, then sure... come up with a way to continue leveraging MSBuild until the asp.net core 2.0 cycle; but at least keep working in the direction of replacing that turd with something the rest of us might be able to work with.

In the meantime, try to keep as much of the config in json as possible. I don't care specifically if it's project.json, or something new and better. If necessary, have the tooling generate legacy MSBuild files on the fly when/if needed --stick them in a sub-folder somewhere or something.

What I don't want is my file system looking like this:

• bower.json
• package.json
• nuget.json
• everything-else.json
• microsoft-old-ass.xml.csproj

Also, can you please fix the 260 character path length limit... please... yes, I know that's got a lot to do with windows, but seriously... it's 2016. .

PS. If you are going to carry on ignoring opposition, can you please provide the following:

• How we'd gain access to the build tools developer slack channels
• A high level view of the current architecture and code, and where the changes to move to MSBuild/xproj are going to be made so we can plan our approach to keep the bits we want and integrate well.
• Assurance that pull requests baking in project.json based tooling will be accepted if meet the quality criteria
• Assurance that if quality criteria are met, we can include "dotnet build" support for full project.json, as well as ASP.NET Simple templates, and potentially some templates for more standard project types as well.

"Be constructive", "don't contribute, don't get a voice". Well, you get what you ask for...

@Mike-EEE, wanna do Xaml serializations for SimpleUseCaseBuild?

After reading all this I came to these conclusions :

• project.json brought a lot of improvements. None of this would have been possible if .net and asp.net core would have been tied to legacy code and tools
• project.json (and json) is not perfect
• xml vs json vs anyserializationlanguage are sterile. Discussions about how to leverage them to answer .net core challenges would be more interesting
• going back to msbuild is bringing back legacy and it probably means that we won't see anymore improvements on the project system, because .net teams are likely to loose some of their freedom

I hope that .net teams will take a deep breath, stall this a bit, gather feedback (and consider adoption and perception of this new stack), and challenge the msbuild approach (which might not be as bad as some of us think) with some alternatives. I think there is need to rush on it.

LOL @shederman what have you pulled me into now?! :smile: And WHAT a discussion! Really amazing.

xml vs json vs anyserializationlanguage are sterile. Discussions about how to leverage them to answer .net core challenges would be more interesting

Yes to me what is important is the backing model used to describe the projects and/or what they do, and some of this conversation has touched on that. I would like to see an improved project model/api that is easier to describe and work with (no matter the format it is described in -- although yes I do :heart: my Xaml!). I have an open discussion on MSBuild's repo here (https://github.com/Microsoft/msbuild/issues/613) in regards to this and also on Roslyn's project system (https://github.com/dotnet/roslyn-project-system/issues/37) as well, if interested.

Lots of really great points here, and I personal am digging the energy, "unconstructive" or otherwise. I think everyone here has their heart in improving MSFT and making the best out of what is being produced. :+1:

My 2 cents:

I believe that there are two kind of people discussing this change:

• developers who have been using VS & .NET for building _various_ kind of projects and have to support those projects for long time
• developers who don't have such baggage and want new, clean and fancy, cross platform ASP.NET Core framework

Personally, I'm in the first category so I want the new ASP.NET Core to be as compatible with other VS project types as possible, and moving to the the "old" csproj/msbuild solution is a win for me (+my team and probably many other developers). This way the transition would be much smoother and clear. Maybe people from the second category wouldn't agree with me (or they just don't care).

The only major problem I see now is how NuGet packages are defined and referenced. It is a pain to have to maintain both packages.config and csproj files (as @JulianRooze already mentioned in https://github.com/aspnet/Home/issues/1433#issuecomment-218606377 ). This has to be refactored. Ideally, it should be done like @cwe1ss suggested in https://github.com/aspnet/Home/issues/1433#issuecomment-218519705 ). It was one of the most constructive comments in this topic BTW...

As for the XML/JSON holy war... IMHO, XML is better for hand editing than JSON. XML supports comments and have more context information when you are looking at it. JSON is better for data, not for configuration files. Merging is equally good and bad for both formats, it is solely depends on the content. If project references would be separated from the current csproj files merging would become much easier as well...

@Funbit trying to categorize people won't help. And I don't fit in any of your categories. I'm a asp.net developer since v1 betas. I almost stopped being one 2 years ago but .net core brought me back because it was clean slate and best of .net and node world.

I want .net core to be a success not an old corporate techno with no adoption and no community.

For my part, I don't really care about this decision, I don't care much for XML, and to steal a quote: "Curly braces are better than angle brackets", but it doesn't really bother me going back to csproj/msbuild - I'm flexible I can cope.

I would like to echo some of @shederman comments though:

The reality is that this isn't really an Open Source Project, it's a Microsoft project, and they've made a corporate decision without our input, and we must just suck it up and accept it. It's been made clear to me that there's basically no possibility that they'd ever reconsider, no matter what opposition there was.

and

To be fair, I'm mostly upset by how this change was made in a closed room without considering or engaging with the community that had taken the previous, very firm support for project.json at face value. Boy, won't make THAT mistake again!

This _does_ bother me, Microsoft has made a big deal of open sourcing .NET and wanting to really involve and work with the community, get their feedback and be a good 'member' (partner?) of the community. But this kind of thing really sets back that whole effort and gives the .NET ecosystem that whole "borgish" feel that the /. community labelled it with for years.

To be fair to Microsoft, they are no the only ones to do this sort of thing with a corporate sponsored project; remember the split in the nodejs community (that caused the io.js fork)? But I think when it's Microsoft, it's a lot worse.

That blew way out of proportion than what was initially intended.

That blew way out of proportion than what was initially intended

@MaximRouiller do you even developer, bro??? :smile:

@Mike-EEE I do. I was expecting some heated argument but I've seen way too much personal attacks. :disappointed:

needing to be able to share source files across projects

@darrelmiller This sounds scary to me, because that seems to imply that listing files in the .csproj is coming back.

@lokitoth There is probably no reason why linked files can't use wildcard globs too.

@MaximRouiller I, too, am guilty of getting revved up and being way too impulsive and speaking my mind. I thought I was bad but @shederman knows how to throw down! Haha. Incidentally, I was going to say that @shederman represents my inner coding animal, but that was before I knew there was a @CodingGorilla. :laughing:

I think we need to to remind ourselves that what we do is really really hard work, and that's when it works! Getting there is even more difficult. In my experience with Silverlight (yes, I got burned baaaaaaad with that, so I know where @shederman is coming from), it helped me to see that maybe I don't know _everything_ (or even _anything_ at times, it feels!) and to keep an open mind about things. I still fail. Even when I saw the project.json initiative I did my best to point out the divide it was creating, but might have been a little too abrasive with the folks here in the repo in doing so.

Anyways, it's always best to take a deep breath, (try to) have a humble spirit, and remind ourselves that we are on the same team, even if that team has been divided into "web" and "native" camps now. It might suck for a little while, but what we're talking about here is something that will serve us for a long time -- a decade or more, even. Let's focus on long-term approach while also having empathy for others and where they are coming from.

OK... enough preaching and rah-rah for the day. :stuck_out_tongue: Back to our regularly scheduled slugfest!

This sounds scary to me, because that seems to imply that listing files in the .csproj is coming back.

Also, as an aside, am I the only person on the planet that appreciates this feature? :stuck_out_tongue:

This sounds scary to me, because that seems to imply that listing files in the .csproj is coming back.

Also, as an aside, am I think only person on the planet that appreciates this feature? :stuck_out_tongue:

@Mike-EEE Yes, I think you are. :wink:

The major use case for linked files is for targeting multiple platforms. That is one feature of project.json that I really want to keep. I don't think I have seen any specific comments about this capability, but it would be nice if the team could affirm their intent to re-create this in msbuild.

@shederman knows how to throw down!
😆

I do try. I do hope I didn't insult anyone though. I tried very hard to only go after arguments.

I get particularly riled up by snide personal insults, so anyone arguing against me, that's NOT the way to shut me up. 😉 And there were quite a few of those.

I'm curious about the use-cases for editing csproj files. My experience is that I have only had to edit csproj files when nuget messed something up, or a hintpath was broken. For adding new steps to the build process I have always used a higher level build.proj file that was run by my CI system. I don't ever use the .sln files in my CI setup.

Is the main purpose that people want to edit csproj files to add BeforeBuild and AfterBuild steps that they want to execute when they debug in Visual Studio?

@Mike-EEE Maybe; I mostly remember it being a royal pain in the butt when dealing with projects with a very large number of files (e.g. Expression Blend, Visual Studio XAML Designer, etc.) to the point that we swapped it out for wildcard selection - which VS does not know how to work with properly, which means that every time I add a file I have to reload the project (or run into "this file is already added" error on build)

What do you actually like about this "feature" (not sharing files across projects, that is obviously useful, but about VS only working properly when every file is individually listed)?

What do you actually like about this "feature" (not sharing files across projects, that is obviously useful, but about VS only working properly when every file is individually listed)?

Admittedly this is a bad habit, but I like being able to remove files from my project when I am doing refactoring. Or even from a historical perspective. If I know I am working on something that I might want at a later time, I keep it on disk but remove it from the project. Granted, this polutes the repo/source control (see: bad habit), but I enjoy that sort of control. Because now, when I want that file, I don't have to go futz around with the history of a repo (how to find this history of a deleted file??? too much work!), I simply "show all files" and re-add it back into my solution. Instant history. :smile:

I'm curious about the use-cases for editing csproj files

For .csproj (every one of these I have done, and for the majority, multiple times)

• If you need to reference UWP types from a desktop application
• If you need to fix up VS breaking things with NuGet (especially around adding a.targets files and .proj/.props includes)
• If you need to change the layout of the generated output
• If you are refactoring projects and renaming assemblies
• If you are doing a large refactoring which impacts a lot of files
• If you had a merge conflict because multiple people are working in the same project and you are not using wildcards
• If you need to understand why the build is suddenly not working (Edit: I should have specified - this is more of a "why I need it to be readable, and 'self-contained'")
• If you need to debug assembly version conflicts due to annoying dependencies
• If you are trying to add a "linked" (shared) file

For project.json

• Creating the file from scratch by hand (critically important)
• Adding/removing NuGet packages
• Changing the target framework
• Changing the output package version

@shederman I realize that you are frustrated, but when you respond with

Really? People still do that? I mean I used to do it for AssemblyInfo.cs, and back in the Dark Ages

You are setting a tone. It's fine to do in a face to face conversation, but in this type of environment, it tends to open the door to a whole range of emotion based commentary that tends to polarize the conversation and makes it hard to focus on the important points. I know it is hard to keep emotion out of these discussions (my tongue is full of bite marks ;-) ) but we really have to try in order to keep the discussion useful.

@Mike-EEE Couldn't you accomplish the same thing (without listing every single file) using the Exclude attribute/pattern? For the record, I often do the same thing, it's very handy when you just want to eliminate something quickly without having to do a commit/rollback cycle.

For the record, I actually like @Mike-EEE's proposal w.r.t. using Roslyn and having the project file be a serialized AST. But only if we can manage to make it equally easy to work with using only notepad. (Yes, I do mean notepad, not notepad++ or anything else more advanced: that's the "smoke test" for the usability of a human-editable file format)

@CodingGorilla I am open to it. I would prefer to see the tooling help me with this (define the pattern for me rather than figuring out how to do it -- if I feel like I am working with DOS again, EVERYONE LOSES!!). I should be able to have the exact same experience as I do now.

So basically, looking at an "opt-out" model rather than "opt-in".

For those wanting to edit project files without unloading.... https://twitter.com/migueldeicaza/status/730978470734401536

For those wanting to edit project files without unloading....

@darrelmiller what am I looking at here... suggesting using Xamarin Studio instead? Yes, that unloading/loading business/workflow/experience is the WORST! It has been around since 2003, heh.

I second the notion that the eventual file should be easily editable and readable with a standard text editor (i.e. notepad), whatever the format is.

I also think better tooling would remove a lot of the pain points behind the current csproj. VS isn't the best example and I think the experience that VS gives you is what a lot of people actually hate about the MSBuild project system.

@Mike-EEE The reply to Miguel's comment was from David Kean who works on the new project system. The team know VS needs to be able to do this also.

@Mike-EEE I guess my thing is, I can deal with whatever they come up with. The MSBuild project system is robust enough to do just about anything (unless as @shederman says, it just _can't_ be XML). I think some people are just staking out the "it must be my way or it's a FAIL", and as someone else said (sorry forgot who, this thread is YUUUUUUGE!) "I try to keep an open mind..." and just adapt.

And besides, you might learn something new, and that's always a good thing. :grinning:

@neoKushan I used to write msbuild scripts from scratch, it is indeed way more powerfull than vs flavored msbuild. But it was not great either, and I'm pretty happy I'm not doing anymore. I think we could work out something way better that this.

@CodingGorilla Actually my main beef is with MSBuild. XML is a problem, but not as bad as MSBuild.

I've offered to do the work myself to keep project.json support running side by side with xproj. He who cares most, does the work, right?

And this is in fact the crux. Will the team allow me to make this contribution? And if not, why not? It is OSS after all, isn't it?

Then, if you like MSBuild and want it's power, you use xproj.

And if you like the tooling that was built for ASP.NET core, you carry on using that.

They use the same underlying compiler.

And it shouldn't even be that much work in any case. All I have to do is refactor out the code that they're deprecating into another command.

Ideally I'd like to be able to use "dotnet build" and look at the dir and decide which one to use based on what files are there. But an option flag on build or even a new command would be okay.

@sandorfr I agree writing fully-fledged MSBuild files that define your _entire_ build process is nothing short of a colossal pain, but if I'm not mistaken that's not what we're actually talking about here - we're talking about _just_ the project structure.

Putting it another way, MSBuild is a huge, powerful system and with that comes a lot of complexity - but only if you use it. VS by default threw a lot of crap in there you didn't need and looking at the xproj, it's clear MSBuild didn't really need it either. If the donet team focus on minimising what's required in the csproj, it should be relatively minimal and clean for most people. The only ones that should suffer "merge hell" will be the ones that want that extra functionality (Which I suspect are the ones driving this change, on their head be it).

There's still nothing stopping you using your build system of choice, be it CAKE or TFS Team Services or whatever.

Again, this is stipulating that the team do it "Right".

VS isn't the best example and I think the experience that VS gives you is what a lot of people actually hate about the MSBuild project system.

@neoKushan That is how I feel about TFS Build and Xaml. Xaml is ridiculously awesome (and would still LOVE to see it used as a possible format for MSBuild "scripts"), but its use in TFS Build has given it a bad name.

I don't think it's productive to use this github issue as a chat window. I wanted to keep the email notifications for this thread in case someone from MS replies but the amount of mails just became too annoying.

MSBuild project system is robust enough to do just about anything

That's part of the problem and what makes it so hard to understand what is going on in a csproj file when reading it, which makes it a poor choice for a project file format (not to be confused with a build definition file format)

(Edit: added)

There's still nothing stopping you using your build system of choice, be it CAKE or TFS Team Services or whatever.

Unfortunately it means that we are stuck trying to shoehorn our build system into MSBuild if we want VS to be able to talk to it (and work properly when there is both managed and native code and we want to debug). This is why, actually, I believe it is a _feature_ to split out the project file from the build file.

Haha yeah @cwe1ss (speaking of tooling improvements!) I was just thinking that GitHub is terrible for when things break out in conversation. We've got like 3 threads here. And I just started another one. :disappointed:

Might I suggest we all jump on the next community standup on Wednesday? I suspect it'll mostly be talking about the release of RC2 a day or two before (one can hope!) but it'll give us all a chance to ping them with the necessary questions and have a good frank discussion with a live audience that can actually give answers.

Might I suggest we all jump on the next community standup on Wednesday?

Only if @shederman represents. I want to see him smash developers and their ideas in real time. Like a WWE PPV event!

I think the advantage of project.json over [projectName].csproj isn't about the format. It is about not needing to be backwards compatible with all the old stuff. That allowed it to be pretty simple. Assuming Damian Edward and team can meet all his specified goals I don't really care about XML versus JSON versus YML versus... What's important to me is simplicity and not having to see stuff that is there for Windows when I'm on Linux.

@glennsills I don't think there's really much of anything in an MSBuild project file that's specific to _windows_, it's more that it's specific to MS Build itself, or other project types that you just don't care about. There's really no need to have a bunch of empty elements just to keep MSBuild happy. I am hoping that the team are planning to cut as much of that out as possible, but we'll see.

@Mike-EEE Only if @shederman represents. I want to see him smash developers and their ideas in real time. Like a WWE PPV event!

I will try to make it. I warn you that I talk slower than I type though, so don't get your hopes up 😄

So, at the risk of opening a can of worms, given https://github.com/dotnet/roslyn-project-system/issues/40 how would people feel about a genuinely cut-down csproj file that only contained (By default) the bare essentials for the project?

(Please don't turn this into an "I hate XML!" tirade).

How about an "I hate MSBuild tirade"?

@shederman

What if we made MSBuild accept JSON files? :laughing: (Couldn't resist)

@shederman it's hard to take any kind of tirade seriously and I would much rather Microsoft took this _discussion_ seriously.

The way this is going in 5 years you'll be programming Swift, Java(!!), Node.JS or Elixir. ;)

There is two crappy as technologies these days in .NET projects/Solutions/whatever. Nuget and .csproj files. If you work in 5+ team using Git (and eg. GitFlow) it's a total nightmare. The "oh crap if forgot to include the file in .csproj" is getting tiresome. Tooling should fix that, tooling should also warn me that I have conflicting DLL versions, tooling should help me with merging.

Cut the crap. Project.json seemed nice at first, but then politics and feelings happened.

MS Team should call it beta, not RC.
It looks like I cannot trust even when RTM will be released, 'case it's possible MS Team decide to ship RTM2 which broke everything again.
I'm not a pessimist but this movement around .NET Core is very weird.

@neoKushan I'll try and be civil and not go on a tirade. That said, I don't believe any MSBuild option is good one, and I also don't believe that XML is a good option.

I'm not agreeing to terms of discussion where I have to give up the positions I hold in order to enter the discussion. I keep hearing how those of us who are for project.json must accept basically exactly what MS have decided, with maybe a minor modification or two.

I don't see how that follows. I simply want the build system that was promised, and committed to. If MS aren't willing to maintain and continue it, I've offered to.

So where's the problem? I'm not asking MS to back out of their plans, I'm not asking them to add work. I'm just asking them to allow me to fulfil the promises that they unilaterally reneged on.

Hardly a revolutionary request.

My 2 cents:

I believe that there are two kind of people discussing this change:

developers who have been using VS & .NET for building various kind of projects and have to support those projects for long time
developers who don't have such baggage and want new, clean and fancy, cross platform ASP.NET Core framework
Personally, I'm in the first category so I want the new ASP.NET Core to be as compatible with other VS project types as possible, and moving to the the "old" csproj/msbuild solution is a win for me (+my team and probably many other developers). This way the transition would be much smoother and clear. Maybe people from the second category wouldn't agree with me (or they just don't care).

The only major problem I see now is how NuGet packages are defined and referenced. It is a pain to have to maintain both packages.config and csproj files (as @JulianRooze already mentioned in #1433 (comment) ). This has to be refactored. Ideally, it should be done like @cwe1ss suggested in #1433 (comment) ). It was one of the most constructive comments in this topic BTW...

As for the XML/JSON holy war... IMHO, XML is better for hand editing than JSON. XML supports comments and have more context information when you are looking at it. JSON is better for data, not for configuration files. Merging is equally good and bad for both formats, it is solely depends on the content. If project references would be separated from the current csproj files merging would become much easier as well...

I also fit in to category one (developers who have been developing multiple projects/types and needs to support them for a long time). My employer has millions of lines of code worth of projects in the csproj format and we also have newer products running on ASP.NET RC1 and RC2 dev branch. Fair warning, we also make advanced usage of MSBuild with custom MSBuild task assemblies, etc.

The real world integration between the two has been a wreck (for multiple reasons), especially considering things like generating wraps, re-generating wraps when wrapped dependencies change, what this looks like in source control (we internally support and use both Git and TFVC), how projects reference each other in a solution at design time in VS versus how they are pulled in at build/deploy time. The system never felt _right_. It didn't make sense that I could have two separate projects, each with only .cs files, but these two project types couldn't co-mingle well.

On that end, I totally understand why it's important to support applications and code that have been written up to this point. I don't think that it's the right time to introduce this type of change, with all the other changes going on - it feels like too much is happening at once.

Maybe a possible future solution is that we take a cue from some other people and think about LTS releases or something similar? This is a much much larger conversation, but then some feature like a project system replacement could be introduced and give people time to absorb it.

Another possible solution is a more pluggable build system, but this is a longer term solution and doesn't help the current conversation. Basically, allow either/or/3rd-party.

About project dependencies, we already have tons of packages.config files floating around, porting them to a packages.json/nuget.json is no big deal. I have more issue with inconsistent assembly binding redirects than I do with the storage format for dependencies.

@shederman You've made your opinion on MSBuild very well known, but what you haven't made clear is your actual _issue_ with MSBuild. This is what I'm finding so frustrating, I just want to know the actual issues you've encountered with MSBuild because I genuinely feel that they can be addressed.

Okay so you don't like XML, all right - the debate between JSON and XML is nothing new and we'll never solve that here. However, that can't be the _only_ reason you hate MSBuild so much. What are the actual problems you've encountered?

The reason I ask - and the reason I keep asking, is that these are the exact problems that Microsoft want to fix and unless we make it clear what the problems are, they won't get fixed. Many of the things we hated about MSBuild are already being fixed that we know of:

1. Listing of every file in the project - being removed/fixed (Actually a VS issue)
2. Merge hell - Fixed by 1. in most cases
3. Unnecessary complexity / Verbosity - Hopefully being resolved by https://github.com/dotnet/roslyn-project-system/issues/40
4. Not easily hand-editable - Again, fixed by 1. and 3.

What's left? Let's actually discuss the problems with MSBuild and see if there's a solution that doesn't involve forking everything or abandoning tens of thousands of intricate, business-critical projects. That's the discussion I _want_ to have.

My 2 cent on this:
Why the hell this kind of change take a place right now? According to roadmap only 1 month left till final release.
When i first look at this i thought that this was a joke. But sadly it isn't.
This is a big slap right in comunity faces. Such decision should have long conversation threads BEFORE it adopted, not after.

@laskoviymishka (and a few others) as has been noted by @neoKushan here, this change is _not_ happening now, this will be a post RTM change (even RTM will be in phases). So all the talk of "why the last minute change" is a bit of a fallacious argument, there _is_ time to see how things will evolve.

@laskoviymishka The change isn't happening before RTM.

RTM will still use project.json like it's used today (I believe the schema is changing for RC2 but that was happening regardless). The move to a "new" csproj is scheduled to happen after RTM and it's going to be done gradually. Nothing changes at RTM (Except xproj gets renamed).

@CodingGorilla this is RC2, which be transfered to 1.0 version in a month. In real world this mean that you stop develop everything and concentrate on stabilization. This change is not really stabilize anything.

@neoKushan if it will happen after RTM, why not asc comunity about it? Start a disscussion thread on github. Start to pointing on arguments etc. Why it should be forced without any conversation with devs?

IMHO this move from project.json to project.csproj should be disscussed before it been adopted. Right now it's not good decision, at least for me.

@laskoviymishka From the community stand up notes: (emphasis added)

In RC2 / Preview 1, there will be no change. In RTM / Preview 2, _the only change you will see if the xproj files will be renamed by Visual Studio to a csproj_. From that point on, project.json will live next to csproj. The team will then begin migrating features from project.json to the csproj file. Its possible that the project.json file remains, and contains all of the package references for NuGet and is renamed to nuget.json. The team has already tested some work that shows you will not need to list all of the files in your project file, one of the key benefits of the project.json model.

So this is mostly a tooling change, and in the very short term (i.e. RTM+) the project.json file will still be there and still function the same as it does now. The good news about this, I think, is there is still time for the community to have an impact on this, if we can keep things civil and constructive.

@laskoviymishka Well, I don't really want to speak for Microsoft, I don't know what their ultimate plan is but I don't think they really know, either. A lot of people are saying that the rug was pulled out from under them and Microsoft should have consulted with us before deciding this, but realistically nothing has changed yet and nothing will change for months - plus when the change does happen, it'll be a gradual change and hopefully one that tooling will more or less do for you.

Microsoft, or at least the asp.net team, has asked for feedback on this and no doubt they are reading these threads, but perhaps what we're missing is a definitive bulletin or post from Microsoft saying "If you want to discuss it, do it _here_". However, I do think the transition is a lot earlier on than people think. So far the only thing they know they're doing for sure is renaming xproj to csproj.

I personally feel that although it's a bit of a crap change to be doing, I do understand their reasons for doing it. I don't have a better answer, so my take is if we have to deal with csproj style projects, then we may as well take advantage of this period to present the best _kind_ of csproj we can. It won't be project.json, but if we can get the best of both worlds then in the long run, we'll all be better off. Not everyone agrees and that's ok.

@neoKushan this is a good point, hope MS will see it. It will be really nice to see any feedback from core team.

@CodingGorilla well there is still change in final version, which is breaking. The main issue of such change is that core team has to spend a lot of time for nothing.This most probably managers issue. Let's spend a lot of dev hours just to change one working thing to another probably working thing. Without any real good reason.

@neoKushan

Let's actually discuss the problems with MSBuild

I'm having a hard time finding enough info to form an opinion. There were a lot of changes that _seem_ to be enabled by project.json and the dropping of .csproj files. I don't want these improvements to go away, but I don't know how moving to a "new and improved" msbuild will change my workflow:

• Currently, we use gulp for every build task. Does that change? My gulpfile just execs out to dnu or dotnet-cli to actually turn a collection of .cs files into an assembly. I can keep that, right?
• Will VS continue to support the task explorer, and afterbuild/prebuild/etc triggers for my gulp tasks, so that VS users can F5 to run? Or do I have to have msbuild kick off gulp which means that all my gulp tasks need wrapper msbuild tasks defined? (ouch)
• Is msbuild in a separate install? Will it be versioned separately from the dotnet cli or the runtime? How does this change the minimum that needs to be available on my CI build server? Minimum to install on a dev environment?
• If I'm using a text editor to add nuget dependencies or .cs files, what extra steps do I now have to add, if any?
• When I'm reviewing a changeset where a VS user added a nuget dependency and a .cs file, will the csproj changes be simple and human-readable? (For comparison, with .net 4.6 and VS2015, my opinion is that changes to the csproj are _not_ easily human-readable.)

I'd like to see the people that are making this change reach out for the scenarios they need to consider (like mine!), and discussion around these to happen. I hope "hey we're moving your cheese without any discussion" kind of thing doesn't become .net core's SOP.

that tooling will more or less do for you

And that's the main crux. The less tooling _required_, the better. I can currently use a text editor and the command line without feeling like I'm swimming upstream. I hope that doesn't change. In .net46 land I have to edit a giant and verbose xml file if I don't want to use VS, and mixing VS users with non-VS users on the same project is a nightmare.

"Welcome to RTM. This is a reminder that your project file will change sometime in the very-near-future. We've already decided this. Reasons, but mostly that we like angles better than curlies oh and build tools, yeah, build tools. We've not determined the final schema (but it will be xml-based, see above), and the file name will definitely be ended with .csproj to throw the maximum amount of confusion into any legacy tooling. Agile. (p.s. if you're a tool vendor: :o)"

@Oceanswave beautiful example how you should not manage your software development

@neoKushan

but what you haven't made clear is your actual issue with MSBuild

Maybe you should read my previous reply to this exact same question from you? https://github.com/aspnet/Home/issues/1433#issuecomment-218993559

I have wasted hundreds of hours over the years fixing, developing and debugging MSBuild files. I've done Team Builds, I've done huge build and deploy pipelines. I've spent hours upon hours poring over verbose logs trying to figure out why the hell some weird situation is occurring. I've paid my dues over the years on this tech, and I personally want nothing to do with it. project.json was a breath of fresh air. After years of suffering with MSBuild, we finally got the impression that MS got it, that a change was needed and was being applied.

And it was glorious. Simple builds, simple edits, quick and easy to understand outputs. It washed away the memory of those hours swearing at the MSBuild scripts. It felt like we were finally uncoupling ourselves from the corpse of the past. But no, now we're shackled back to the corpse we hate so much, despite the promise that this would not happen.

Without discussion, without review, without any kind of engagement at all.

The fact that you're not even aware of how much MSBuild is hated in some quarters simply proves that you didn't do any diligence on this decision.

I don't believe MSBuild has any significant functional limitations as a build system. It is incredibly powerful, and in a sense that's it's main weakness. It's complicated because it has to handle so many scenarios. For a simple "restore, build, test, pack" scenario it really is a huge overkill.

In my teams, we're dealing with C# developers. They're under pressure, tight deadlines, high stress. They do not want anything which gets in their way or delays them.

MSBuild is a different way of thinking, a major context switch from imperative coding. The devs simply hate it. They find it obtuse and counter intuitive. They avoid it. The only MSBuild that's created in any of the teams I supervise these days is tool created.

I haven't met a single C# developer in the past 5 years or more who is excited by, or enjoys working with MSBuild. Look at some of the comments in the past few days on Github. I am by no means alone in my dislike of MSBuild. MSBuild has been perceived as a millstone around .NET developer's necks for a decade. Is much of that perception unfair? Yeah, quite probably.

But so what? From my perspective as Head of Software Engineering, I need tools that produce the outcomes I want. I don't get those outcomes with MSBuild. I do get those outcomes from project.json + gulp.js + powershell.

_Can_ MSBuild get me those outcomes? Sure it can, but only if the developers do the work in MSBuild to get those outcomes. And they just don't. When we force them, they do it, and then don't maintain it.

I can't rely on a tool that the devs hate. That's the simple reality. And considering how much I've loved not using it myself, I can't actually blame them.

Let's actually discuss the problems with MSBuild and see if there's a solution that doesn't involve forking everything or abandoning tens of thousands of intricate, business-critical projects.

Okay, so, what can be done?

About 5 years ago, if some of the changes being discussed now had been introduced, I think the perception would be better. But they weren't and now it has a major negative mindshare among a huge number of developers. As I recall some of these same issues were raised with MSBuild back then, and rejected. Just as current issues are being raised, and rejected.

I don't know how it can recover that, I really don't. I think there would have to be some major clean breaks. How do you make them without breaking what's there? It's too little, too late. So I don't see a path forward with MSBuild, not for me, not for the devs that work for me, not with my partners, or the teams that work for _them_, not at the clients we consult at. None of those audiences wants to use MSBuild, they use it in the tooling because they have to, and they swear about it repeatedly. Admittedly normally around merge time.

So _now_ you want to make merges better? 10 years on. After the tool is a swearword in many quarters?

Fundamentally you're using a tool designed for Build Masters in the late 90's that is actually being used by developers cutting their teeth post 2010. A tool using inference for it's logic being used by developers used to imperative work, and imperative tools. A tool that uses a very flexible, but non obvious way of setting properties being used by developers that think a property sets are a simple assignment operator and don't understand why you would even want to do a PropertyGroup and don't care to find out.

That's the discussion I want to have.

Sure, I get that. The discussion I want to have is different though, it's "give us what you promised us, or let us give it to ourselves, because we don't like your oldnew idea, and we do like what was promised".

Can I share something sad? Out of my business partners, who have similar lengths of experience to me (more actually), I was the most pro-MSBuild back in the day. I actually _used_ it. I learned it. I built big pipelines. But that was over 5 years ago, and much water has gone under the bridge since then.

Man I find myself nodding profusely while reading @shederman's comments and history as it is very similar to mine. I have spent so much time in MSBuild and its DSL and have really been bit a few times (not to mention the amount of time soaked by having to learn it it). Its syntax and approach is unlike anything in .NET and that is part of the problem (which is why I say reboot/redo/improve its object model and give it another go). That would be my primary concern: it is so legacy that the way it approaches problems is unlike anything else (.NET) developers have to work with, and this alienates the product, rather than promote interest/adoption.

Think: Visual Studio Extensions (.vsix). No one wants to touch those because of how legacy/old/different they are compared to everything else that is out there these days. Well, you have SOME developers that want to, because they have paid their dues in learning its arcane system -- just like MSBuild.

I, too, am probably the most experienced among anyone I know professionally who has ever dealt with MSBuild. Most developers do not want to take the amount of time to learn it (because you most definitely do). It's almost as if it is its own language.

If it was "more .NET-like" (and had better integration w/ VS) then I think we would all agree that it would be a better product to work with and attractive proposition to consider.

@Mike-EEE & @shederman To Mike's point, its old, archaic and "unlike anything else (.NET) developers have to work with...". But is it beyond repair? They've admitted that there are problems with it that they want to fix, so the question is: Can it be fixed? I think I know @shederman response, I even mostly agree with his reasoning (I agree with the theme that build and project systems is an odd mixture of concerns).

Again, I don't have a horse in this race, I don't mind whichever path they choose to go. I just really like getting thumbs up reactions and hearing myself speak (with a side of actual intellectual interest in the conversation :laughing: )

I just really like getting thumbs up reactions and hearing myself speak (with a side of actual intellectual interest in the conversation :laughing: )

Happy to help! :smile:

But is it beyond repair? Can it be fixed?

Depends on who you ask, really. Bringing up issues on their repo as @shederman suggests has been difficult and challenging (and yes, I censored my words there :stuck_out_tongue: ). It seems they are set in their ways. But, as you know with the nature of software, anything is possible given enough time and effort. :wink:

@PhilipRieck You're asking some really great questions! Unfortunately I don't have definitive answers for all of them, but let's see:

Currently, we use gulp for every build task. Does that change? My gulpfile just execs out to dnu or dotnet-cli to actually turn a collection of .cs files into an assembly. I can keep that, right?

I don't _think_ this will change, I am 95% confident that what we're talking about here only affects the project _definition_, not how the project is actually built (At least beyond calling dotnet build). The dotnet CLI might call into MSbuild at some point but by that point it's an under-the-hood kind of thing.

Is msbuild in a separate install? Will it be versioned separately from the dotnet cli or the runtime? How does this change the minimum that needs to be available on my CI build server? Minimum to install on a dev environment?

I have zero definitive answer to this, but I would _imagine_ that MSBuild comes as part of the dotnet CLI as a completely separate install, even if you've already got MSBuild installed already (Say with VS). Pure speculation on my part though. I know that a huge goal of this whole ".net everywhere" project is to have the minimum amount of fuss to get people developing. Should be literally apt-get dotnet-cli (or whatever), dotnet new, dotnet build. You shouldn't ever have to call into MSBuild to build the project, that's dotnet-cli's job.

If I'm using a text editor to add nuget dependencies or .cs files, what extra steps do I now have to add, if any?

For .cs files, definitely nothing else, just as today - the one thing they've been very clear on is that the days of specifying every .cs file in your project are behind us (though presumably you can still do that if you want, looking at you @Mike-EEE). As for dependencies, certainly in the short-term (short term being months), they'll stay in project.json and work exactly as before. There's a chance that project.json will become nuget.json and so aside from a name change, nothing else changes, but there are other possibilities for this and this seems to be one of the main things Microsoft is very unsure of - let your voice be heard on your preferences for this.
(My personal preference is being able to do something like .nuget.json but that's just me spitballing).

When I'm reviewing a changeset where a VS user added a nuget dependency and a .cs file, will the csproj changes be simple and human-readable? (For comparison, with .net 4.6 and VS2015, my opinion is that changes to the csproj are not easily human-readable.)

For the .cs file, the csproj shouldn't change at all. For nuget dependencies - good question, again this is up in the air somewhat. It really shouldn't cause the csproj to change but the big decider at the moment is if nuget should live in nuget.json or if csproj should have that stuff - and if they're separate, how difficult is it going to be to corral the two?

And that's the main crux. The less tooling required, the better. I can currently use a text editor and the command line without feeling like I'm swimming upstream. I hope that doesn't change. In .net46 land I have to edit a giant and verbose xml file if I don't want to use VS, and mixing VS users with non-VS users on the same project is a nightmare.

I do completely and utterly agree with this, but Microsoft has invested far too much into their cross-platform efforts to suddenly make it a nightmare to do. By "tooling", I suspect it'll be down to the .net CLI rather than VS or anything like that. Don't forget, the ultimate "End game" for .net core is to be a very agile, very fast-moving platform but one that doesn't force you into having to spend time upgrading every couple of weeks. I'm _pretty sure_ that if you write a dotnet 1.0 application in June, it'll still build and run years from now, but newer versions will be a case of running "dotnet upgrade" or something along those lines when you're ready. Even when RTM hits, RC2 projects will still build and run RC2 bits until you actually go in and change the target to be RTM (I think in global.json or somewhere?).

:laughing: When I read threads like these, I have to wonder if Microsoft has moments of regret. I really respect and feel for the guys who have done and are doing their utmost to turn Microsoft inside out, with a goal of making a transparent, open-source, community-minded haven for developers. The guys behind this transformation do care. They are the good guys. They have to be between a rock and a hard place right now; the less-than-constructive community sentiments floating around (while entertaining me) aren't helping their case.

I would like to point out that replacing a bunch of magic project creation functionality that currently exists in the IDE with a command line app doing a lot of magic csproj manipulation is a bad idea. Making the project definition file as simple as possible is a must. The nicest part of project.json is that I can read and understand it.

@shederman Your issue with MSBuild is that in a large, complex system it's large and complex....

I've also worked with Team Builds and I've also absolutely hated it (Pinging @Mike-EEE becuse we've both talked about how awful this experience is), I do get it but what you're describing is a completely different scenario. MSbuild _can_ be big and complex and by default VS _makes_ it big and complex - but that's what's changing.

The newer csproj file should be a hell of a lot smaller, which means "Debugging" should be greatly simplified. No (or little) cruft. You can still use whatever _build system_ you want, hell you can call a .bat file that just calls "dotnet build" on *.csproj and you'll get the output you want, just like today. Let the dotnet cli deal with MSbuild and you shouldn't even have to touch it.

@neoKushan no thanks.

I want what was promised, not lipstick on what we were told we were moving away from.

And if you don't want to give us what was promised, just let us give it to ourselves. It's all there already. It should be just a case of keeping the refactorings. I'll do the work, as I've said before.

I suspect the number 1 reason that there's no appetite to leave it in is the realisation that this would be the start of a massive migration away from MSBuild projects. I'm sorry, but keeping an outdated technology on life support is not one of the design goals of .NET Core. Is it?

Biggest issue with ms build in who will fix it, and how much time it takes. Right now whole ASPnet projects got more than 1000 open issues, some of them really critical. Look at SignalR.
There is a month till release, and this bugs mot really close to final state.

And now they says that ms build could be improved. Does MS have enough resource to manage all this legacy shit 💩? Does community can handle it? I not really believe in it.

@shederman

And if you don't want to give us what was promised, just let us give it to ourselves.

They're not preventing you from doing ANYTHING. Go ahead and fork it, nothing is stopping you. If you're waiting for Microsoft's permission, then you've already got it, you got it the second they open-sourced the code.

It's all there already. It should be just a case of keeping the refactorings. I'll do the work, as I've said before.

Then do it? Again, nothing is stopping you.

I suspect the number 1 reason that there's no appetite to leave it in is the realisation that this would be the start of a massive migration away from MSBuild projects.

Why would they even care? What difference does it make to Microsoft if you use MSbuild or something else?

The real number 1 reason is that ASp.net core's project structure is only really good for asp.net core. There are hundreds of other project types out there that just wouldn't be suitable to project.json. Never mind the fact that project.json has its own issues, which we've apparently all forgotten about - lack of comments being my pet peeve (and no, suggesting some-other-format-as-long-as-its-not-XML does not help).

I'm sorry, but keeping an outdated technology on life support is not one of the design goals of .NET Core. Is it?

No, but helping people port their old, existing projects to .net core is a goal. Besides, we're talking about the .net core version of MSBuild, not the fully-fledged desktop version, there is a difference.

Your only problem is that they dared call it MSBuild. Had they come up with a new project style that happened to be XML but was called "CoreBuild" or something, you would be none the wiser and all you'd have to go on is "I hate XML!".

you're waiting for Microsoft's permission, then you've already got it

Not quite true. I don't want to fork it, I want to maintain it in the main repo. There's a difference. So no-one has to download a whole new .NET SDK. I want it in the tooling, and for that, yes I do need their acquiescence.

Your only problem is that they dared call it MSBuild

No, that they want to _use_ MSBuild. Slight, but important difference. Rename the new project.json build system and call it MSBuild and I'll use it happily.

you would be none the wiser and all you'd have to go on is "I hate XML!"

Maybe 😄

Anyway, going round in circles.

Going to bed.

I say leave it for the standup. Nobody is convincing anybody. I'm pretty sure I understand the pro-MSBuild side, but I don't agree with it. And I'm pretty sure the pro-MSBuild side understands the no-MSBuild side, but don't agree with it.

All I'm saying is we can have both. For no (or very little) extra effort from the MS team. Then let the options sink or swim in the glare of actual production usage.

Per @neoKushan's question:

What's left?

I actually want to frame my response, if I may, around the "tenets" I outlined above w.r.t. what I believe makes for a good, usable project file:

• It should be human editable/readable

Taking @neoKushan's statement above to mean that it will be addressed - I'm assuming someone at MSFT said/wrote this. With that said, I want to see an MSBuild-based proposal where this is actually addressed first, before "committing" (as a Community / Framework) to MSBuild.

I'm assuming getting rid of the Guid ProjectType is one of the top items to be addressed?

But I stand by my addendum above: It is a hard (non-negotiable) requirement that for simple projects (e.g. ASP.Net Hello World in Angular), I can create the entirety of it by hand, in notepad. If I need to use Yeoman/VS/similar, we have failed at proposing a human-editable project file.

• It should allow for comments

Already working, in MSBuild

• It should be declarative

Changing the order of First-Level (direct children of ) can change the entire meaning of the project, often in difficult-to-debug ways. Nowhere is this more notable than if you bring the .targets imports to the top by accident.

• It should be self-contained

This is my biggest problem with MSBuild. Reading a file, statically, does not give you enough information to actually know what is going on there. From .targets files that come from _environment variable_-specified paths, and the very fact that environment variables are event supported, to conditionals and imports, together you get what is effectively a Turing Complete environment, at the cost of a very high level of complexity, and poor tool-ability. I posit that VS's abysmal integration of MSBuild is a consequence of the difficulty of building tools around such.

This is similar to the human readability/editability concern.

• It should be designed to reduce merge conflicts / simplify merging, if possible

MSBuild technically supports this in the form of wildcards. VS support for wildcards is worse than abysmal. It actively makes it harder to work. Per above, I am willing to accept that this will be fixed - but it needs to be an item on a _proposal_ to _migrate_ (and it is a migration to, because all of the messaging so far as been about project.json) to MSBuild-based project files.

• It should be fully documentable (with self-containment principle applying to the documentation)

I believe MSBuild has documentation. That documentation, especially for the VS _flavor_ of MSBuild leaves quite a bit to be desired. I am often perplexed why different things are in the groups they are, and VS "helping" move them around is not very helpful.

A perfect example is the Bond NuGet package. How many people know that if you do not have a the BondInclude folder on disk (if it is referenced in the csproj), the build will mysteriously fail to actually generate any of the Bond types into the resulting assembly? (With no error spew, either). Then creating an empty folder with that name and reloading the project fixes it.

(Yes, I know, I am going to file a bug on it)

• It should be tool-independent

Let's say I do not want anything to do with MSBuild (let's say because I am feeling contrarian, without going into it further); I just want to define my project, and pull in packages via nugget. Why am I forced into using this particular build system? Especially if all I want is to define a project?

A build definition file is not a project file format. That VS managed to get it to work (somewhat) is not good reasoning for continuing to use it as such. I want a real file that just represents the project itself, and information about the artifact it generates (not instructions how to build it). In this, even project.json fails because it allows us to define "commands". Why do those exist? Just define what the type of output is, and where it can be found.

I read this whole thread, and one thing that stuck out to me in this discussion of project.json vs project.csproj is that only one of those filenames has an entire programming language baked into it. I prefer to do ASP.NET development in F#. Is that even possible in ASP.NET Core? At this point I haven't the faintest idea, but I get the feeling it's not. I'm not even sure if people are using csproj as a shorthand for csproj, fsproj, vbproj or if they really mean csproj only.

Update: the F# folks are working on CoreCLR support, but there's no real ETA yet. My point is that whatever project system is decided on now will affect programming languages that don't seem to even be on people's radar right now. As much as I prefer JSON over XML, if project.json is going to lock me into C# (and file-order in compilation is crucially-important in F#) then I'm not for it.

For now, it looks like it's back to FAKE and Paket for me...

I'm working with .NET since the beginning and I've never had any noteworthy issues with MSBuild. The main reason for that is, that I've never used it for anything else than the out-of-the-box solution compilation.

And that's what I don't get about this dislike for MSBuild. No one forces anyone to use MSBuild for anything other than solution compilation. And I think, being able to compile a solution is a pretty useful feature - which BTW does not even exist in "dotnet cli" yet (you manually have to loop through the projects right now - correct me if I'm wrong).

Your actual build system doesn't need to change. If you're using Nant, keep using Nant. If you're using psake, keep using psake. If you're using a powershell script, keep using that. Etc! Most probably, only the "dotnet build" part has to be replaced with a call to MSBuild. (Maybe not even that wil be necessary if dotnet build calls into MSBuild)

I'd argue that this makes MSBuild a pretty unimportant implementation detail. That's how I've seen it for the last decade and that's how I will continue to see it.

But of course, as I've already said in the beginning of this thread, what we definitely need are some of the _features_ of project.json and Visual Studio to treat the csproj better - and I don't see why they wouldn't be able to deliver that.

@jtmueller There's absolutely no _technical_ reason why you shouldn't be able to use F# (or VB.net if you're so inclined). I wouldn't be surprised if part of the shift to MSBuild project files is to help facilitate that. DNX was never really happy with it, but CoreCLR definitely supports F#. I don't know if you'll be able to use F# come RTM but it's definitely in the pipeline.

@jtmueller project.json is pretty much a project definition with dependency manifest, plus custom commands. There's nothing there tied to a specific language at all.

My dream build system (to replace MSBuild entirely) would use Roslyn to figure out the tasks and targets, allowing you to use F# to define your build process (or C#, or VB.NET, anything Roslyn supports).

Of course, nobody's proposing that yet. But locking us back into MSBuild will almost certainly close that door for a very long time.

Had a nice rest, and though a bit about the challenge of what needs to be done to "save" MSBuild. I don't believe we can or should turn MSBuild into a significantly different build system. It's an inference based, XML defined build system, and that works for it, and quite a lot of people's scenarios, especially some of the more complex scenarios.

But not all of us have dedicated Build Masters who can wrangle with MSBuild. Not all of us need the power that MSBuild's complexity brings. Some of those that do need that complexity don't want to use MSBuild. On one of my teams for example, all the custom build logic is done in pre and post build steps, Exec is essentially shelling to Powershell. Not because it can't be done in MSBuild, it can, and in that case probably _should_. But because they don't want to do it in MSBuild.

Step one is definitely that we need to separate project definition out of the build system. To me that makes immense sense. We can discuss splitting dependencies out of project definition, but I don't believe that is required.

Step two is that we do need a build system. We need to handle very simple use cases, as well as highly complicated ones. But no rule says one build system has to handle _both_. To my mind, what makes the most sense is to have a simple, lightweight build system that basically just builds the project definition. It does restore, build, test, and pack.

I think we should also look for a way for it to be able to work _without_ a project definition at all, using the directory structure as the definition. Obviously such a situation would mean it'd use the default framework and default dependencies. Maybe possible, maybe not. But we can look at each element in the definition and ask "can we infer an intelligent default for this"?

But while that's probably enough for 80% of use cases, it's not enough for the other 20%. They need something more. (caveat: opinions on ratios of use cases may vary).

Step three is that we allow a very simple form of extensibility to that build system. But we're talking very simple. Basically, it can run it's basic build, or it can run an external build system. Said external build system can be MSBuild, or scripts, or some other build system.

I'm happy that the new build process should be able to shell out to MSBuild, but I don't believe that something as (IMO) old, cantankerous, and bloated as MSBuild should be the basis for all builds in the future.

With things like Web frameworks, we see the MS teams iterating frantically. Because they're got competition. They have to worry about Nancy breathing down their necks for example. It's _easy_ to switch to something else. And it makes MVC/WebAPI better for it.

With MSBuild baked into the entire .NET tooling, it becomes a pain to use anything else. Where's the competition? And you can see the effects of that in the MSBuild Github board. Just go review all the Closed proposals. The only reason that they're talking about making these "slimming" down changes now is because they want people to move from project.json to MSBuild.

If MSBuild had been baked into .NET Core from the start, I believe we would be seeing _none_ of the movement we're seeing now from the MSBuild team. But what happens once we're locked back in? Once competition is basically excluded? What's going to happen? What always happens in no-competition scenarios, and what has happened for years up to now: just enough improvements to stop mass defections, but nothing particularly interesting.

People asked me how I think we can "save" MSBuild. I believe opening it up to real competition and choice is the only way. Enforcing it by fiat on all developers, even those who don't need anything nearly that powerful (yes, I do believe it's powerful), will only breed even more resentment against it.

That's not a recipe for success of any framework.

Please all, keep in mind, we all want .NET to succeed. I _love_ .NET, I think C# is one of the best programming languages out there, and have enjoyed it's slow transition to Scala - The Good Parts™ 😉.
I don't believe we start afresh with .NET Core, and do it by shackling ourselves to one of (IMO) the worst parts of old style .NET. Yes, MSBuild, but no, not shackled to it.

By all means keep it, but not front and centre built into the core of the system.

My dream build system (to replace MSBuild entirely) would use Roslyn to figure out the tasks and targets, allowing you to use F# to define your build process (or C#, or VB.NET, anything Roslyn supports).

YAAAAAAAAAAS!!! Speaking of which... is this the right place to have this conversation? We have the Roslyn and MSBuild repos too and they seem like they should be involved as well. I guess we are trying over in MSBuild repo, but they are (as you mention) very rigid and inflexible. I think having more people over here like the interest this thread has produced might go a long way towards reform.

Step three is that we allow a very simple form of extensibility to that build system.

A provider-based build system/model?! GENIUS! I approve of this message.

Btw, if you get your wish and have access to your own build system, I suggest we call it... BERSERKER BUILD! Named after "Berzerker @shederman"... my new nickname for you. :smile:

@Mike-EEE Don't get too excited. By no means am I proposing anything as drastic as all that _yet_.

For now I think it should just be Steps one and two, with MSBuild support for Step three.

But this kind of possibility is what I though we were moving towards when we got project.json, separating project from build so that it'd be easier to swap out build providers. To my mind bringing MSBuild back into the root closes out these possibilities. Or at least makes them far less likely to get traction.

Right now custom builds don't gain adoption because the root system _is_ so powerful. It's a hard conversation to convince people you want to use a non-MS build system when the MS build system can actually do everything that is needed (ignoring pain).

is this the right place to have this conversation

I don't think so, no. Also, don't think know that it's the right time yet. We need to close this issue out before seeing what directions are possible.

BERSERKER BUILD! Named after "Berzerker @shederman"... my new nickname for you. :smile:

Not sure how to feel about that 😉

Not trying to be a berserker. I just don't want to move backwards when we _were_ moving forwards.

Hey guys, maybe instead of reinventing the wheel (nuget.json or whatever it will be called) let's use existing, community driven solution which is solving most of dependency management problems - Paket.

1. It has concept of transitive dependencies
2. It's integrated well with MsBuild
3. It has human readable file format for defining dependencies
4. It has very good migration path from packages.config
5. And many other features (but apparently those 4 are most important things for everyone, so I won't mention things like Git dependencies or better package resolution strategy)

@Krzysztof-Cieslak remember that the biggest reason Microsoft is pushing MSbuild project definitions is to help ease the migration of those who've invested a lot into MSBuild. That regard, Paket is no better than project.json (or project.yaml or project.cs or whatever).

Having said that, I still don't see any reason why you can't use whatever build system you want. Ultimately, "dotnet build" isn't going to change, regardless of what format your project definition ends up being, dotnet build will still generate your output.

@neoKushan Yes, but will "dotnet build" require an MSBuild file even if we're not using MSBuild? Will it build if there's no MSBuild file at all? Or will it shell out to MSBuild that will then shell out to whatever other build system ise used?

@shederman No doubt "dotnet build" will be using MSBuild in the background to actually build the projects, but whether or not we really see any of that is very much up in the air. Currently, today, you need a project.json to properly build your projects, if not for references then for other important data (like target frameworks). Eventually some (or even all) of that is going to migrate into a csproj file so one presumes that you'll need that .csproj for dotnet build to work, no matter what it ultimately uses in the background. However, how much impact this really has to you remains to be seen.

As I said, just as long as I'm allowed to do the work keep the lightweight build in place, which doesn't require any MSBuild at all, I'm happy. You guys can build your self referential "MSBuild everywhere" pipeline down whatever dead end you want.

But if that's going to work, then csproj will need to include project.json like RichiCoder suggested.

That way the "core build" and "MSBuild" can work side by side, or core build can work without MSBuild. And, obviously, if you don't import the project.json, you can define your project properties in the csproj too.

Quite an easy change actually. Off the top of my head we need to:

• Keep the existing dotnet-build code and have it run in certain (to be determined) circumstances.
• In others have it run MSBuild, as per DotNet core teams plans
• Have VS able to read either project.json or MSBuild for project properties
• Add ability to Import project.json to MSBuild

Quite a small amount of work, and it allows Microsoft to continue it's "MSBuild forever" path, and it keeps the promises made to the .NET Core community, and it allows those of us who want to opt out of MSBuild to do so.

It's notable that no one from the asp.net membership has said anything here.

Meanwhile, I re-read some of the Notes from the ASP.NET Community Standup – May 10, 2016, and they talk about a "new" MSBuild system, but don't say what it is, except that it won't require Visual Studio to edit. It sucks that it wasn't designed into asp.net and has to be added (now) so late in the game...when the design didn't include that to begin with. Really, project.json should just include a { "BuildSystem" : "MSBuild" } item if you want/need to go that route. I also wonder why MS couldn't (famous last words) "simply" allow comments in json files via the tooling.

@rhires From my understanding the "new" MSBuild system is a few tweaks to make the XML a little lighter, such as including all cs files into the build, and offloading the dependencies to a nuget.json file. No significant changes in MSBuild design, architecture, or usage.

I like your project.json idea. Was just going through the RC2 changes, and they put in "testrunner", so there's no reason that couldn't be done. _BUT_, it appears that their hearts are utterly set on removing project.json entirely, and going back to an MSBuild-first world.

why MS couldn't (famous last words) "simply" allow comments in json files via the tooling

There's no reason why they couldn't. JSON.Net, the library they use, supports comments.

Really, project.json should just include a { "BuildSystem" : "MSBuild" } item if you want/need to go that route.

Why would I want my project to dictate it's own build system? Surely the build system builds the project and not the other way around?

@neoKushan:

remember that the biggest reason Microsoft is pushing MSbuild project definitions is to help ease the migration of those who've invested a lot into MSBuild. That regard, Paket is no better than project.json (or project.yaml or project.cs or whatever).

Paket is not new build system, it's dependency manager which is 100% compatible with MsBuild. It just solves problem of packages.config.

@Krzysztof-Cieslak I never claimed it was a build system and dependency management isn't really a major problem with .net core (As far as I'm aware, at least). .net core doesn't use packages.config it uses project.json.

If .Net Core was still planned to use project.json we wouldn't have this 100 post discussion. ;) All I'm saying is that suggested in many places solution of using "nuget.json" for handling dependencies is reinventing the wheel as we have product which does exactly the same.

@shederman

"Final survey results: 100 responses, for a 9 million .NET developer population that's ±10% with 95% confidence."

Yes and asking at a conference about cat toys which is the preferred pet a dog or a cat might give you similar results.

@darrelmiller

"I think it is important to make a distinction between MSBuild and the way Visual Studio currently uses MSBuild. I have been hand editing MSBuild files for years and use them for all of my projects. E.g. https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj"

Shall we discuss the VS specific build files on top of the project files where msbuild does not work from the command line?

@gregoryyoung We should. I've done build files that depend on devenv before, but haven't see ones that will not run from the command line. Any examples?

@gregoryyoung

Yes and asking at a conference about cat toys which is the preferred pet a dog or a cat might give you similar results.

That's an interesting analogy. Except...

I posted the link on Twitter feeds of people who _supported_ the move to MSBuild. So, actually not at all like your analogy.

And I love the continued slurs that the survey was biased, in the wrong forum, or unscientific. But, the questions weren't leading, the answers had a broad range of responses, and the survey, yes was a self selected audience, but a broad one that, in theory at least, should bias _away_ from my point of view.

I've also got the impression, and in some cases confirmation, that the people making these accusations have just googled a bit about surveys. I personally have designed a master's level research protocol for a health study, and whilst I won't claim the survey is perfect, it certainly is not as flawed as the Microsoft employees are making out.

It most certainly _is_ statistically significant, and it is giving you a good indication of where opinion lies. GitHub, and gitter, and Twitter, and blogs are all backing it up to one degree or another.

Multiple sources of evidence saying the same thing. If you want to ignore the opinions of a significant of your users, say so. Stop trying to wave their opposition away as if you lose your right to voice your opinion if you hold the "wrong" one.

Or better yet, as I've said many times, create your own survey that improves the things you think are wrong with mine.

The reason I did the survey is that it was utterly clear that Microsoft had no clue what people were thinking. What is becoming utterly clear now is that they have no _interest_ in what people are thinking.

Stop being dishonest with yourselves and with your community and engage with the opposition instead of waving it away.

Stop trying to change the facts, and start changing your mind based on the facts.

@shederman I don't have the impression that the Microsoft team really answered this thread (including your survey). Yes one guy of the team said he was not considering it as trustworthy as you do but that's all. I think there is still hope they are currently talking about the massive opposition to the path they are taking and they are discussing about the right course to take and will respond to us when they know more.

I think we can give this team some credit ;).

@gregoryyoung Sorry, from the analogy you gave, I assumed you were an MS employee, since they've been trotting out the same approximate line for 2 days now.

@sandorfr

I think we can give this team some credit

I thought we could, but my experiences in the past few days have not reinforced that hope.

I have to think it's not "the team's" fault, but someone higher up in the organization who made this decision and imposed it down...and then "the team" has to suck it up and make it look pretty. BTDT. Not fun.

You all do realize that project.json has already been undergoing big changes recently in order to make it a bit more compatible with non ASP.NET Core applications? If you just look at the example in that anouncement post, it already becomes pretty bloated with all that build configuration.

Going from that to a “classic” csproj file actually doesn’t seem to be such a far stretch to me. And if the csproj itself also evolves a bit in the more flexible direction we have learned from the project.json, I actually can see the “new and improved” csproj work really well. And I think we can safely assume that those recent changes to the project.json wouldn’t have been the last ones in the course to make it usable for _all_ kind of .NET projects—I think it’s important that we do not forget that there are many other targets other than ASP.NET (Core).

And it actually shouldn’t matter much whether the file format is JSON, XML, or whatever. Yes, one might be favorable over another for various valid reasons, but in the end you should think about how much time you actually want to spend within a project file. Yes, with the problems we have experienced with the current formats we spent more time than we would want, but ideally, assuming we fix those causes, we should spend an incredibly tiny fraction of our time in those files. And at that time, you shouldn’t really need to care about what format it is in. Especially if it’s eventually all tool-assisted (including full completion in editors).

I feel that when people think about project.json, they mostly think about the early stages which was a lot about convention over configuration. Yes, that was super nice, but also very specific to ASP.NET Core and as such very limited. It won’t really work well for other targets, so it makes sense to use something that has been working well for many years and expand upon it and improve it in every way possible while maintaining compatibility.

So, tl;dr: Yes, I really like project.json and wish there was a way to keep it for ASP.NET Core (e.g. using a special MSBuild task). But at the same time, I do completely understand why this is happening now, and I think that it’s actually not a bad thing they do. Of course the timing is a bit weird, but given that the change will not happen parallel to the ASP.NET Core and .NET Core release, I don’t think the timing is an actual issue (assuming that the transition later will be smoothly).

needing to be able to share source files across projects

@darrelmiller This sounds scary to me, because that seems to imply that listing files in the .csproj is coming back.

@lokitoth Assuming the csproj will work similarly for file references as the newer project.json, there is nothing that prevents you from using globs in general and having individual file references along side with them.

@shederman I am not a MS employee just a rational person. If you google me I am sure you can find I have a long term interest in the platform.

There are many pros/cons associated with the change, but what you have provided is not useful to any sane discussion.

This was a disappointing change to hear about. project.json, automatic file inclusion/globbing, and transitive restore were the first things about ASP.NET Core that made me go "oh, nice!" at the beginning.

I realize not all of that would be going away (I hope?). But going back to an XML project file feels bad, because historically that has meant headaches for humans. I hate opening a csproj file to fix a problem because it's a wall of difficult-to-parse text.

Just my two cents.

Looking at the changes in @poke's post it looks like they basically translated the csproj into json, which honestly is pretty yuck too.

Based on the fact that they want to support the Compile, Embed, CopyToOutput, Exclude, Shared Files etc options then really the json format wasn't going to work any better than XML anyway. I also suspect that json wouldn't have worked as well for heavy build script customisations.

I only hope that this is the team trying not to add yet another half baked solution into production until they can have time to figure out a way to do it nicely.

@gregoryyoung what you have provided is not useful to any sane discussion

Great. Okay, let's see, what have I provided:

• I have complained about the the move to XML, as have a large amount of others
• I have complained about the move to MSBuild, as have a large amount of others
• I have tried to get an understanding of the reasons and evidence behind the decision, which has not really been provided besides some very hand wavy stuff
• I have tried to get to the underlying _thinking_ behind the decision, which has _also_ not really been provided
• I have asked the community for their opinions, which MS has not bothered to do at all
• I have tried to come up with alternatives that allow the outcomes stated by the people giving the reasons, but also allow the community to keep their simple build process that they enjoy
• I have offered to do the work required in order to support said alternatives

Can I ask, out of interest, what's the insane part? Interrogating someone's thinking is not rational these days? Or did I leave something out there?

I mean, I'm angry, don't get me wrong. I've wasted a large amount of work, time, and money building around a core promise of the framework that's been yanked away at the last minute in what appears to be a rash and poorly thought out move. Do I not have a _right_ to be angry?

PS. Ah, you're _that_ Greg Young. Respect. Love your work. I really do.

@bzbetty I agree with you utterly. The last thing I'd like to see is a reimagining of MSBuild into project.json. One of the biggest problems with MSBuild in it's current form is that it conflates a _project definition_ with a _build process_.

So going and adding a build process into project.json would be making the exact same mistake MSBuild/VS made.

The project definition should stand separately from the build process and be fed into the build process.

And then one has to ask: if your project is simple and just needs to straight build of the project definition, do you really need a heavyweight, extensible, customisable, flexible, and counter intuitive build system just to do a simple build?

Put it another way. If you _had_ such a simple project definition, and a very simple build tool that could do nothing more than build the project definition, would you then choose to install and use an MSBuild or a NAnt or suchlike?

No, probably not, right? I mean why add unnecessarily to complexity. A core part of effective software engineering practice is to keep things simple.

But, once you hit a scenario that the simple "build the definition" tool could not handle? Sure, _then_ you would.

I'm saying, install both tools side by side, so we can pick which one is best for our needs. MS are saying: no, you only ever need the complex and counter-intuitive tool, but we'll remove the most egregiously bad features.

Soapboax

I'd just like to share a little research I've been doing. I've been looking at Twitter, Slack, Github, Gitter, and Jabbr.

I've seen very little support for the move outside the core team. I mean, there has been some, but not much. Most people are pretty upset about the move.

I have also been pretty dismayed by the tendency of many in the pro-MSBuild camp to infer that their opponents are misinformed, or, more commonly, unqualified. This has been matched by the tendency in the pro-project.json camp to infer poor motives (myself included, mea culpa).

I would like to ask the following:

• People to assume that the people holding differing opinions from their own hold them for good reasons. They are not deluded, incompetent, complicit, or crazy
• People to attack arguments and evidence and not people
• Any evidence provided should not be dismissed out of hand without firm reasons

Arguments for
The main reasons I've seen advanced for the move to MSBuild are:

• Tooling support - To allow round tripping between different tools, e.g. VS, VSCode, Xamarin, etc.
• Existing investments - Large clients have existing builds that cannot afford to be thrown away
• "Muscle memory" - People are used to MSBuild

Arguments against

• Existing investments - investments made in .NET Core tooling: post RC. RC _should_ mean no major breaking changes
• CSProj/MSBuild nasty - past negative experiences in dealing with csproj and MSBuild
• Step backwards - Move to project.json was move to a new way of working, partly to attract a new gen of devs. This is being undone

Opinion
I have paid for a full SurveyMonkey subscription so I can access the full set of results (rather than the 1st hundred). It's 321 responses, which would normally translate to a ± 5.5% margin of error, 95% confidence for a 9 million population.

The common arguments I've heard against this survey are:

• The questions/answers are biased: I don't believe that, and even if they are, they're not by much. A broad range of answers exists.
• The survey was posted to a biased audience: Twitter? To followers of the various team members timelines. Not sure how that's a biased audience.
• Not scientifically relevant: Okay, got me on this one. I didn't do a full research protocol, so it wouldn't pass peer review. Is that the level of certainty required to gauge support for a proposal?

Here they are:

My appeal to anyone who loves the .NET framework is not to underestimate the level of angst about these changes, and to take the feedback on board and engage with the community about it on the basis that their concerns are valid, and come from informed experience.

And if the decision is to go ahead regardless, a better set of reasoning and evidence should be provided than has been so far.

Man @shederman reminds me of me (and many others) when Silverlight ate it, except x10 and more focused/experienced. It's probably why I support him :100:%! haha.

One of the biggest problems with MSBuild in it's current form is that it conflates a project definition with a build process.

So going and adding a build process into project.json would be making the exact same mistake MSBuild/VS made.

The project definition should stand separately from the build process and be fed into the build process.

:+1: :+1: :+1: ... Excellent way of framing the problem!!! You know, I have had my nose in this for so long, that this never really occurred to me. But you are (again) 100% on-point.

I hate opening a csproj file to fix a problem because it's a wall of difficult-to-parse text.

This needs to be framed somewhere, @nbarbettini! Perfectly captures my sentiment as well.

And it actually shouldn’t matter much whether the file format is JSON, XML, or whatever.

Yeah I hate to try to remind people of this, but it seems that some developers are stuck to the notion of formats, and that is misleading. The "JSON" project paradigm isn't really a "JSON thing" but uses JSON as its choice of serialization to describe its "model." The fact that JSON is terse and less chatty than XML made it all that more appealing (to most).

Correspondingly, MSBuild isn't rooted in XML, per se, but the way it has been designed is to have its "model" described in this format. I say "model" because both of these systems suffer from a (what I consider a) design flaw of placing a document model in front of the actual model/API that ultimately gets deserialized into memory. That means having to manage more artifacts and concepts than truly necessary, and ultimately complicates the system. Hardcoding it to only accept a particular format (XML or JSON) only makes it worse, and again we should explore ways of mitigating this constraint.

Anyways, lame Sunday morning PSA for everyone. :stuck_out_tongue:

I couldn't see this posted anywhere in this thread, so here it goes... https://youtu.be/N9MteJH-HsQ. Hopefully it explains a bit more about why the change is being made.

@shederman

"Can I ask, out of interest, what's the insane part? Interrogating someone's thinking is not rational these days? Or did I leave something out there?"

I was referring to the survey results and trying to extrapolate to the general developer population. As I mentioned it is roughly equivalent to running a poll which are better dogs vs cats at a cat toy convention and assuming it applies to the overall population, there is a large and obvious sample bias.

GitHub on my phone won't let me +1 @gregoryyoung, but +1.

The team have explained that part of the reason for the change is the acquisition of Xamarin, which is a big deal. The potential to share libraries between .NET, ASP.NET and Xamarin mobile/x-plat projects is immense, and if that means compromising the project/build file format, it's a worthwhile trade IMHO.

I'm going to wait and see what the tooling and the final file setup looks like before i form a final opinion.

@gregoryyoung I was referring to the survey results and trying to extrapolate to the general developer population...there is a large and obvious sample bias.

Which sample bias would that be? The one where it was posted primarily on Twitter feeds of people who _like_ the changes? The one where it was on slack channels that the dev team uses?

The main sample bias I see is that the respondents are probably engaged, informed, and passionate. Sure, that's likely not a representative sample, but I would argue that it's an important one. And even with sample bias, does that mean that the results must be thrown away? That the respondents viewpoints don't matter?

322 professional .NET developers have expressed an opinion. Are you going to ignore their input totally because you believe (without any evidence to back you up) that it is unrepresentative?

Apparently, a blog post will come next week, we will have more specific things to discuss then.

Jeez people need to calm the heck down :)

I agree this change seems big but I think its going to effect people a lot less than it may seem. Remember that when the team talks about "tooling" that also includes the cli. Any conversion that needs to happen will also be done by the cli, "tooling" for adding references, that I argue is even better than typing them into either json or xml, will be in the cli. Globbing is already supported in msbuild. Msbuild will obviously be included in the don't sdk so there will be no additional installs, the new project story will also be the same, the dotnet commands will just do other things under the hood. (I'm not a microsoftie, but this seems highly probable)

The team are not idiots, they don't make this change lightly. They've _have_ given reasons, primarily compatibility and coherence with the rest of the platform across languages, native references and project types, granularity of nuget packages and so on. Its only been a week and they have said they will detail the changes and their reasoning very soon.

I wish people would at least wait for that and what their actual plans are before condemning the move completely.

And yes, I've hand debugged csproj/tfproj files and battled conditional rules for file inclusion and all that stuff. Heck, ive even written custom build tasks. But at the end of the day, its much easier to abstract away a complex system with simple tooling (cli included), rather than making the relatively simple project.json system support all the complex scenarios it needs to support.

Put another way, that simplicity people loved in project.json was already gone, it needed to go to support the complex reality of a generalized dotnet environment with all kinds or projects and scenarios. Had they implemented all that into project.json, you'd basically have msbuild again. I much prefer them taking a step back and looking at the build system as a whole rather than tacking on feature after feature to project.json until it becomes a big ball of spagetti

Lets just see what they are suggesting and then raise specific issues if we find fault with that :)

@aL3891

If the team clearly explain their reasoning and the alternatives that were considered, and why they were rejected, and also consider and engage with the proposals that have been suggested here, then I'm bang alongside that, and will support any well reasoned solution that comes out of such a process.

In fact, this is exactly what I've been asking for, for three days now. Insight into the decision making process and the evidence that backed it up. The information that has so far been provided in this regard has been underwhelming at best.

If we get it, +10 from me.

@aL3891 Quick question. Some people were saying we should attend the Wednesday stand up to address these issues. Are you saying we should rather wait for the blog post?

Everyone should also remember that this is all open source. If you feel strongly that the non-msbuild is better, just fork the existing tooling and keep it going. As with all interesting software design choices there are pros and cons for all sides of the argument. Microsoft needs to be responsive to their big paying customers but to their credit, they have made all this stuff open-source. If something else works for you do it.

I watched that youtube video that @khellang posted - ASP.NET's changes were _revolutionary_, but it looks like, in the end, it was too revolutionary, and now with Xamarin in the mix, _revolutionary_ isn't going to cut it.

In addition, the idea of re-inventing the wheel didn't seem appealing, when it seems like that was actually the right thing to do...but legacy again.

I have a new-ish critique of using MSBuild, based on the .NET standup - whereas we have a good separation of concerns in a number of places, MSBuild does not. Roughly, according to the standup, it somehow has to know about everything to be effective, and merely orchestrating different pieces isn't good enough.

Meanwhile, and I'm thinking this should go in another thread - it seems like there are "internal engineering decisions" that later get shared with the community. This makes me think that MS doesn't completely get open source - had they had these discussions out in the open (and made people aware that they were occurring), it would have been less of a surprise and we might already have answers, and lots of stakeholders (and I mean the customers who would be negatively impacted by a move away from MSBuild) could have made their positions clearly known earlier, and the community could have reacted in a more timely fashion on issues/concerns and even solutions to the problems presented...Instead, "it was our only option," is why you open source not just the software, but the development process, too. This how the maxim "given enough eyeballs, all bugs are shallow" is supposed to work. I don't know how big the engineering team is at MS, but it's smaller than the overall community, and there is some seriously good talent in the community who might be up for a challenge such as the one that the engineering team decided was unworkable...and it probably is for them, but not the community at large. Open source is about using the untapped resources and talent that is out there.

On the other hand, maybe I missed something somewhere?

@shederman I would suggest those with a vested interest both attend the standup and keep an eye out for the blog post (which will almost certainly be linked here).

For those unaware of the standup, go here: https://live.asp.net/

You can add it to your calendar and it's a worthwhile watch even if you don't care about the project definition change.

@shederman I don't feel I really have authority to tell anyone what to do, but I can tell you what I'll do. Heck, I'm just an outsider same as the rest, I don't _know_ anything :) I think the standups an on.net shows are a great source of information, especially early hints at what's coming, so I'll certainly watch those. if they say I blog post is coming i'm going to at least give them the benefit of a doubt and see what they have to say. But i'll probably leave comments/ask questions on both.

The latest on.net episode, linked above provided some good insights though

There's also the roslyn project system repo that's most likely going to see a lot of action in the coming months

Does somebody have a TL;DR on the on.net episode?

I think I'm highly unusual in _hating_ watching videos about programming. Give me text anytime 😄

Bloody hellfire! I'm even non-IDE in my learning methods 😱

I think I'm highly unusual in hating watching videos about programming. Give me text anytime :smile:

What's the problem? It's _only_ an hour of your time. :grin:

@rhires

Dude. That is quite possibly one of the very best posts I've seen on this issue in the past 3 days!

Small price to pay to stay on the bleeding edge imo, but to each their own ;)

Basic tl;dr:
The team started to get feedback both from internal customers like xamarin and external ones that migration for existing projects to project.json was difficult and getting project.json to work together with exsisting projects as well as other toolchains such as native ones and ones for other platforms like android would mean bringing in significant amount of code (or concepts) from msbuild. This would take a lot of time and effort and slip the release by a unacceptable amount of time as well as slow down future work (including for other products like xamarin studio and mono develop, as well as visual studio plugin developers).

So instead they opted to instead base the build system on msbuild but bring in the stuff people liked from the new system. As for the timing, the xamarin acquisition wasn't known even when RC1 was made but now that its done it changed a lot of stuff.

They also recognize that people are very fond of project.json and they are as well, and that they want to retain as much of the goodness from that, perhaps even enabling msbuild to read project.json files as well via a target. Cli and VS-less scenarios is also something they see as a core scenario. They also talk a bit about other build systems and the goal is to enable people to use other things than msbuild if they want

Then they talk a little about RC2 and what's shipping in there and also they reflect on what they could have done differently regarding the project system migration, being more open earlier and having more of the conversation on GitHub and so on.

I do recommend watching it, i'm probably missing some finer points here.

@aL3891 - thank you for the great summary. It was a slog to go through the video. I agree that they should write up a text summary. I noticed that they are "learning", and still uncomfortable with opening up their process, even as they say it's a good thing. So hopefully this will be a good learning experience for them and we will see the changes and be the beneficiaries of it.

@aL3891 Thanks for the summary!

Small price to pay to stay on the bleeding edge imo, but to each their own ;)

Ah, but I'm not on the bleeding edge, I stay a little back from there. Just far back enough not to cut myself, or at least so I thought when I adopted .NET Core post-RC1 😢

@shederman given that "post-RC1" is basically nightlies or source, how exactly do you like your steak?

@neoKushan I meant that we only "adopted* .NET Core _after_ RC1 was released. We're still on vanilla RC1.

So, we like our steak medium rare. But we just cut into a really uncooked bit and are shouting for the waiter.

But it's okay, I've stopped calling for the waiter, and have now called the maitre'd (our Group Microsoft partner representative) to come and see me and we can discuss decision making, information dissemination, and platform direction.

We Know Nothing!

We have not been given enough information, too much theory and conjecture in this issue. Quick summary for the lazy who don't want to read this thread:

What We Know

1. xproj will be converted to csproj.
2. We 'might' have a nuget.json file.
3. We are using msbuild.
4. This will all happen in stages.
5. The libraries won't change.
6. You will not have to specify every file in csproj.

What We Don't Yet Know

1. Will csproj compile to .nupkg's?
2. Will csproj compile to multiple architectures and targets at once x86/x64 dotnet/dotnetcore?
3. Will there be a separate nuget.config file.
4. How will commands be handled to execute npm/gulp/bower/etc.?
5. Will we be able to use dotnet build as well as msbuild? I'm totally up for the 'one .net' that @shanselman aspires to.
6. Will intellisense for project references remain or go away?
7. Will the VS tooling or command line be good enough that we don't ever have to edit the csproj.
8. Will we get dotnet add reference MyAssembly tooling?

I think this issue should be closed until we have more information.

I'm totally up for the 'one .net' that @shanselman aspires to.

This one? :smile: :+1: :+1: :+1:

I think this issue should be closed until we have more information.

but but but... then what will I do with my life??? :cry: :grin:

@RehanSaeed

And what if I have problems with the "What We Know" list?

Must I wait for clarity on the "What We Don't Yet Know" list before raising my concerns?

Or must I just shut up and suck it up?

As I am well aware a great many people would like... 😉

From everything I have seen the decision is 100%, unchangeable on:

So what more do I need from "What We Don't Yet Know"?

@shederman You really may want to watch the On.Net Video. It gives a bunch of reasoning behind the decision.

fyi: I usually change the speed to 1.5 to watch it faster. https://www.youtube.com/watch?v=N9MteJH-HsQ

If we're going to stay with an XML-based project file, then please please PLEASE can you suggest/encourage/require that tooling put the file contents in some kind of order. And "chronological" is NOT an acceptable order. The biggest pain I've found with the proj files is the difficulty merging them. Just alphabetize them at least. Yes, we'll still have the occasional merge problem, but I'll take "occasional" over "omnipresent" any day.

@MelGrubb the one thing we do know is that the new project layout will NOT list all the files present, it'll be just like project.json does it

For anything that is expected to be managed by hand, TOML please.

JSON makes no sense whatsoever for configuration. It makes even less sense than XML.

For anyone interested, it looks as though the RC2 bits are available (No blog post yet that I can see)

https://www.microsoft.com/net/core#windows

and https://www.microsoft.com/net/download#core

My two cents, fwiw:

I have loved the simplicity of project.json. Here's what I would like (and not like) to see in MSBuild-based tooling:

• MSBuild should not be tied to VS or any other IDE/editor. It should be a standalone tool that can be installed on its own. (Or included as part of the dotnet cli install.) I say this because I've had to install a full VS instance on build agents just to get MSBuild. That never made sense to me.
• MSBuild (or dotnet cli containing MSBuild) itself should be installable with a command line -- whether apt-get, chocolately, homebrew, powershell or bash/curl. If I can't install this as part of a fully automated setup of a build agent (e.g., in circle.yml or Dockerfile), it will be a roadblock and a source of pain.
• MSBuild should be very command-line friendly. I ought to be able to do anything from the command line -- and therefore be able to automate anything in a build process -- in a circle.yml, bash or other script file. And I'd like to see good use of stdin and stdout, so I can pipe in/out of MSBuild commands.
• Working on a .NET Core project in VS Code (or another non-VS editor) should not require VS-specific information in a csproj file or anywhere else. Project info, nuget package dependencies, platform targets, compiler directives, etc. should be sharable across developers using different IDEs/editors. Those make sense in a project file. But people not using VS should not have to see VS tooling settings -- those belong in a separate file.
• The project file(s) need to be easy to understand and easy to edit by hand. Tools are awesome, but I should be able to open the file and understand what the tools are doing for me. And make changes easily.
• Although I know there is no difference in functionality/capability, I have a strong personal preference for json over xml. I also think using json will help attract developers coming from other stacks. It's hard enough attracting people to .NET without making one of the first things they see a big, hard-to-decipher XML file. (This is more emotional than logical, but I do think it matters.) Please at least make json an option, and use that option in yeoman generators and other new project templates. At worst, please quickly accept the inevitable pull request implementing a simple json format in the MSBuild repo.
• Would be nice to keep the npm-style "scripts", so I can easily share the commands used for dev, test, debug, build, run, docker build/run, etc. with my team. Those could go in their own script files, but they make sense (to me) as part of the project file.

@jtbennett

"But people not using VS should not have to see VS tooling settings -- those belong in a separate file."

Just to add there is also a bunch of stuff in other files now that should likely be put into the msbuild file. Ignored things are a good example of this providing project files are still supported. I can't tell you how many projects I have seen that built in VS but not from command line

@jtbennett

MSBuild should not be tied to VS or any other IDE/editor.

It won't be tied to VS at all, it'll be delivered via Nuget so it's not tied to anything.

MSBuild (or dotnet cli containing MSBuild) itself should be installable with a command line

This isn't changing from today, you'll still be able to install dotnet cli via the usual package sources.

MSBuild should be very command-line friendly.

_MSBuild_ will be effectively part of the build itself, so I don't think you'll need to pass in command line options. However, donet (CLI) will obviously be command-line friendly and I think this is all you want/need.

Working on a .NET Core project in VS Code (or another non-VS editor) should not require VS-specific information in a csproj file or anywhere else.

I completely agree with this. Hoping that the "new" project format will be much more simplified.

The project file(s) need to be easy to understand and easy to edit by hand.

They've said that this is a priority for them as well.

Although I know there is no difference in functionality/capability, I have a strong personal preference for json over xml. I also think using json will help attract developers coming from other stacks. It's hard enough attracting people to .NET without making one of the first things they see a big, hard-to-decipher XML file.

I find this interesting, I personally feel that XML is much easier to decipher than JSON but I think a lot of that comes down to how well designed the schema (For either) is. I've had to decipher some god-awful XML in the past with really awful element names (like "Element") and while MSBuild is by no means the worst offender in that regard, it certainly leaves a lot to be desired. With JSON, the key name can suffer the same problems.

Anecdotally, I recently had to work on a project where someone tried to embed JSON into XML elements :(

RC2 blog post now up: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

.net core post is up as well https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

Thanks @neoKushan !

@michaelvolz I don't think that file is going to stay, if this is to be believed: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file.md

System.GC.Server (old: gcServer) - Boolean indicating if the server GC should be used (Default: true).

and

We could use a different format for the deps file, but if we're already integrating a JSON parser into the host, it seems most appropriate to re-use that here.

Seems a bit odd for them to have XML for the _project config_ but .json for the _runtime config_?

Seems a bit odd for them to have XML for the project but .json for the runtime?

Does it now? :laughing:

@Mike-EEE Good point! I have updated to hopefully clarify what I meant :kissing:

@neoKushan no you were right the first time. :smile: I was agreeing with you in my snarky, borderline-counterproductive way. :smirk_cat:

But yes... 100% agreement that having different formats within a solution is maddening. Having a single format across the board reduces complexity, context-switching, and therefore _confusion_. It's one of the reasons why I want to see MSBuild enable different formats and become format agnostic. Oops, warning, shameless plug. :grin:

I think I'm going to be a follower of your holy crusade @Mike-EEE, since we are stuck with msbuild let's make it better.

Hey thanks @sandorfr ... please feel free to contribute to the thread there (even if it's a reaction/:+1:). I'm feeling a little alone there and definitely walking into contested territory! From my perspective I would be very open to improving my product to increase adoption/favorability/usability/likability if there were a slew of customers forced to use my product for whatever reason. But I'm not in charge of it, so. :stuck_out_tongue:

@Mike-EEE I read some of the thread, I'm so depressed now... You stepped into the legacy world of legacy minds :D.

Let's hope the people at Microsoft will be more open to your ideas because I'm actually fine with msbuild only if the thing is made more simple and straightforward and I don't need a Gui to edit my project (yes json intellisense was way better than usual visual studio project tabs).

You stepped into the legacy world of legacy minds :D.

Wellllll-said @sandorfr ... wellllll-said.

For those unaware of the standup, go here: https://live.asp.net/

OK I am a total slacker and finally checked this out just now. Looks like the next standup is next week? Is the team skipping this week?

@Mike-EEE Interesting, it was definitely scheduled for tonight at one point, but I wonder if it has changed. I tweeted @shanselman, hopefully it's just a mistake but given RC2 only came out yesterday, they may well want to skip it this week.

OK cool @neoKushan ... just making sure sanity is bolted upon my head for once. To be certain, I wouldn't want to be so quick in dealing with all of our questions and discontent, either. :wink:

from Slack:

jongalloway [9:31 AM] I'm pretty sure ASP.NET Community Standup tomorrow is cancelled - both shanselman and damianedwards are at OSCON.
...
davidfowl [9:34 AM] damianedwards: is back ... but shanselman is at oscon
...
jongalloway [9:46 AM] Yeah, ASP.NET Community Standup is definitely cancelled for 5/17. I updated the site.

@Mike-EEE dealing with all of our ... discontent

😆

In case there was any doubt left: https://twitter.com/shanselman/status/732585321775267842

have to skip. I'm at #vslive and OSCON

There is one thing I enjoy a lot with project.json: all files are included by default in the project, without the need to explicitely include each one of these. With large projects (I mean thousands of files), the merge process was really painful because of XML, but also because of every file being listed in the csproj.

Do we know if there is going to be any improvment on this side ?

@pierrus It was mentioned that they don't want to go back to the days where all files were listed inside the csproj.

@MaximRouiller OK didn't know that, great !

@MaximRouiller but they do want to go back to the days where MSBuild was the One Ring™, I mean Build Tool. 😉

_Ash nudertog vegal durbatulûk, ash nudertog vegal gimbatul,
ash nudertog vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman I've moderated my point of view since my first reaction to the news.

My thinking is that they initially wanted to ship the project.json format but normalizing the model with csproj/Xamarin would just require them to push the framework even longer. The quicker gain was to merge back to csproj. They could keep the new way in a separate file while keeping the pure "data only" inside the csproj. That for me explains the RC2 massive work that was done.

If you move properties that barely change and keep the cool new features in a separate file? We don't really lose anything. Yes we're going back on the monster... but we're not too far off.

I don't have any insider knowledge on this. This is pure speculation on my part.

Anyway... we're not ending up in a yearly release cycle anymore. If they are ready to transition from project.json to csproj post-RTM, I'm assuming that bigger changes could be released post-RTM too.

Changes that no one but the MS Team are aware of.

@MaximRouiller I can't work off "possible" changes that _might_ be coming down the line.

I just work off the announced changes, that they are moving off the lightweight build, onto using MSBuild and xproj for everything.

Yes we're going back on the monster... but we're not too far off.

Um, if we've _deprecated_ something that is working for 90% of use cases to move _back_ to something that is overly complicated for those use cases, well I have only one question:

Why?

Why is dotnet build calling MSBuild when msbuild already does this quite well. Why deprecate simple build? Why do extra work? The only reason is simple, the decision has been made that we must all use MSBuild all the time for everything, for ever.

something that is working for 90% of use cases

[citation needed]

Even assuming it is 90% of use cases, would you work with anything that failed 1/10th of the time?

move back to something that is overly complicated

Again, [citation needed], the only thing that we know so far is that it'll be the XML-csproj and that it won't contain the file list. We know nothing else about how the system will work and I'm not convinced we even need to know, because everyone here is just calling "dotnet build" and regardless of how the build is achieved, that won't be changing.

Why is dotnet build calling MSBuild when msbuild already does this quite well.

Have we gone from saying MSBuild is "overly complicated" to "MSbuild already does this quite well"? Currently, dotnet build only _seems_ simple because everything that happens in the background is hidden from you. Switching to MSbuild doesn't change this, as far as you're concerned it's still just dotnet build.

For someone that keeps saying there needs to be a distinction between the project system and the build system, you are unwilling to accept that there is in fact a difference between having MSBuild XML files as the project system and having MSBuild as the build system - there is a separation already.

working for 90% of use cases

@shederman Please stop assuming everything is ASP.NET… You come off as _willfully ignorant_ in this thread. I suggest you to calm down for now until we actually get more information about the new project system instead of just assuming everything is doomed.

@shederman The reason you build a shim over something is when you want to replace it. Abstract it so you can change the implementation. We do it every day. It's called refactoring.

I hope that it's replaced. Besides the XML, I think it's also slow compared to other things if I remember correctly.

If it be like dotnet build the question is - how hard it will be to change underline build process? Does it possible to replace msbuild to something different? How much duct tapes it will require?

If we could make such change in 1 or 2 skeins of duct tape,well its acceptable.

@neoKushan Have we gone from saying MSBuild is "overly complicated" to "MSbuild already does this quite well"?

Um, no. I do believe I was saying that the command msbuild runs MSBuild quite well. I was making no judgements on MSBuild as a tool. Was that not clear?

@neoKushan Even assuming it is 90% of use cases, would you work with anything that failed 1/10th of the time?

Nobody is saying anything about anything failing. Some tools are more fit for some purposes than others. I would say that MSBuild's power and complexity is fit for purpose for about 10% of builds. We can argue about the exact percentages, but it's definitely less than 100%.

@neoKushan Switching to MSbuild doesn't change this

Um, it doesn't change the build process no. It _does_ however change what is needed for the build process to work (i.e. csproj file), and the speed at which it is performed.

@neoKushan you are unwilling to accept that there is in fact a difference between having MSBuild XML files as the project system and having MSBuild as the build system - there is a separation already.

Sorry, but I don't see how having one tool do two things is a separation.

@poke Please stop assuming everything is ASP.NET

I'm not. I'm saying the proposed solution doesn't work that well for simple builds. Some of which are ASP.NET builds. Personally I don't see why I need something as powerful as MSBuild for a simple Console App either.

@poke You come off as willfully ignorant in this thread.

I hope so, yes. Because what I'm wilfully ignorant of are the wonderful benefits that accrue to users of MSBuild.

@poke I suggest you to calm down for now until we actually get more information about the new project system instead of just assuming everything is doomed.

Dude, I'm calm I promise you.

I'm just not letting points of view I disagree with stand unchallenged. I promise you that it's not a sign of agitation. Goodness sakes, I didn't even get agitated by some little twerp _person_ calling me ignorant 😉

Which is kind of ironic when this selfsame little twerp _person_ is calling for me to calm down.

Funny really.

@MaximRouiller @shederman The reason you build a shim over something is when you want to replace it. Abstract it so you can change the implementation

Ah yes, and that would be a good reason to do it, except from what I've heard there is no intention to replace MSBuild. It is the selected build system for the foreseeable future. I would like it if we please allow projects to stand without MSBuild specific items, and if dotnet build were to either do the existing lite build, or to select a build tool based on something, e.g. config. If you want to use MSBuild, by all means create an msbuild file and run msbuild.

Um, no. I do believe I was saying that the command msbuild runs MSBuild quite well.

To put this into context:

Why is dotnet build calling MSBuild

dotnet build does far more than "just" call the compiler, take a look at the current CLI's implementation of dotnet build. Building one project is just part of the dotnet build process. Eventually _part_ of that process will be to call msbuild but that's not your job, that's the job of the CLI.

I was making no judgements on MSBuild as a tool.

All you've done in this thread is judge MSBuild as a tool. To claim that you're doing no such thing is, frankly, ludicrous.

Was that not clear?

Very little of what you say is clear, or at the very least well thought out.

Nobody is saying anything about anything failing. Some tools are more fit for some purposes than others.

So some tools fail at being fit for purpose.

I would say that MSBuild's power and complexity is fit for purpose for about 10% of builds.

Well that's interesting because every single Visual Studio .net developer out there would have to disagree. You're effectively saying that MSBuild is no good for 90% of users (ignoring the fact that you're pulling figures out of your arse), which is - again - ludicrous.

Um, it doesn't change the build process no.

If the process is unchanged, then your only argument is that you don't like the structure of the project - the fact that it's MSbuild or whatever behind the hood is thus completely irrelevant.

It does however change what is needed for the build process to work (i.e. csproj file)

That is literally the only thing that's actually changing as far as people will see.

and the speed at which it is performed.

[citation needed]

Please show me how the new process is any faster or slower, given that it currently doesn't exist.

Sorry, but I don't see how having one tool do two things is a separation.

Because one tool is not doing two things, MSBuild may be the build system but the change is to do with the project system. There is absolutely nothing stopping you from using a different build system if you want, it's just non-trivial.

I'm not. I'm saying the proposed solution doesn't work that well for simple builds

dotnet new
dotnet restore
dotnet build

Please show me how the proposed solution changes anything about the "simple build" scenario

Some of which are ASP.NET builds.

yo asp-net web
dotnet restore
dotnet build

Personally I don't see why I need something as powerful as MSBuild for a simple Console App either.

You don't. You just need dotnet build. Which you'll still have. Nothing changes there.

I'm calm I promise you.

little twerp

:-1:

@neoKushan It would be really nice if you could please grasp the concept between a response to a quoted extract and a comment about the entire discussion. I'm assuming you're _capable_ of doing that, so the only conclusion is that it's deliberate. If so, just letting you know that it's an intellectually dishonest tactic. I would hope you knew that, but I'm giving the benefit of the doubt here.

I also think you should definitely take a chill pill. We're just discussing what we individually believe is best for the framework, we're not trying to _fight_ each other. Attack the argument, not the person. Well, that's what I've been _trying_ to do for quite a few days now (except in one case recently, see below).

Well that's interesting because every single Visual Studio .net developer out there would have to disagree.

Funny, I've collected evidence that says something different. Where did you get yours?

Because one tool is not doing two things, MSBuild may be the build system but the change is to do with the project system. There is absolutely nothing stopping you from using a different build system if you want, it's just non-trivial.

Yep. So we agree. I'd just really, really like it if it was trivial.

Is that really such an unreasonable request? Really?

You don't. You just need dotnet build. Which you'll still have. Nothing changes there.

And dotnet build will do what exactly? Shell out to msbuild? Why can't we just use msbuild if we want to use MSBuild? What exactly is the purpose of dotnet build in that situation? What does it add to the tooling?

little twerp 👎

An attempt to be funny, but you're probably right.

@poke I apologise unreservedly.

It would be really nice if you could please grasp the concept between a response to a quoted extract and a comment about the entire discussion. I'm assuming you're capable of doing that, so the only conclusion is that it's deliberate. If so, just letting you know that it's an intellectually dishonest tactic. I would hope you knew that, but I'm giving the benefit of the doubt here.

Literally no idea what you're referring to.

I also think you should definitely take a chill pill.

...

Attack the argument, not the person.

:InsertRolleyEyeEmoticonHere:

Funny, I've collected evidence that says something different. Where did you get yours?

Okay cool, so where did the 10%/90% figure come from?

Yep. So we agree. I'd just really, really like it if it was trivial.

Which has nothing to do with them changing to msbuild, you'll already have trouble changing out the current build system away from dotnet build.

And dotnet build will do what exactly? Shell out to msbuild?

What's different to dotnet build calling msbuild instead of dnx or roslyn?

Why can't we just use msbuild if we want to use MSBuild?

So you want to use MSBuild now? Nothing is stopping you, it's a nuget package these days. Go nuts. I'm surprised you're even asking though, given how much you hate msbuild.

What exactly is the purpose of dotnet build in that situation? What does it add to the tooling?

Are we actually discussing the merits of dotnet build? You don't like dotnet build? You don't understand the purpose of dotnet build? That doesn't seem likely. What is it you're trying to ask?

@neoKushan please stop antagonizing him. this is not constructive.

Okay cool, so where did the 10%/90% figure come from?

That came from my personal experiences. I've found that about 90% of the builds my team and I have created in the past few years have required nothing more complex than what the RC1 dotnet build does.

Which has nothing to do with them changing to msbuild, you'll already have trouble changing out the current build system away from dotnet build.

Please clarify, I'm not sure what you mean here.

So you want to use MSBuild now? Nothing is stopping you, it's a nuget package these days. Go nuts. I'm surprised you're even asking though, given how much you hate msbuild.

_sigh_. My question is: why should dotnet build shell out to MSBuild when msbuild does that really well already? Why have two commands do one thing?

I've asked this about three times so far, and every single time you've either misunderstood it or misinterpreted it.

I am asking about the actions of two different command line commands
I am asking why both will do the same thing
I am asking, if they both do the same thing, why not have one command
I am asking what the second command adds to the situation if they both do the same thing
I am passing no judgement on the quality of the underlying tools in that context, although I may have done so elsewhere
Said judgement elsewhere does not impact on the question being asked, as the question being asked is about the command line commands and their actions, not on the underlying tools at all
I am not trying to discuss what else said tools may or may not have done in the past, merely what they are intended to do in the future

Sorry for the lengthy exposition explaining a one sentence question, but it's apparently necessary.

An rticle on InfoQ:
"Microsoft has come to the conclusion that the project.json experiment has failed and will be shifting back to using .csproj files." :disappointed:

Like I said, perception matters.

My question is: why should dotnet build shell out to MSBuild when msbuild does that really well already? Why have two commands do one thing?

Because they don't do just one thing?

Why should MSBuild shell out to csc when csc does a fine job of building stuff already? Why have two commands do one thing?

Why should dotnet test shell out to the xUnit test runner when it already does a fine job at running tests on its own. Why have two commands do one thing?

Why should dotnet restore shell out to NuGet when NuGet does a fine job of installing packages already. Why have two commands do one thing?

You get the idea... (I hope :wink:)

@sandorfr

@neoKushan please stop antagonizing him. this is not constructive.

I'm not deliberately antagonising anyone, I am point-for-point deconstructing @shederman's argument, which is exactly what he wants people to do:

Attack the argument, not the person.

Though at this point, I'm not even entirely sure what @shederman's argument even is as we seem to have somehow gone from XML being bad, to MSBuild being bad to now dotnet build is bad.

Let's carry on.

That came from my personal experiences.

This is your "evidence"? Which, remember, you put in bold:

Funny, I've collected evidence that says something different. Where did you get yours?

And now it's "Personal experience". That's what we call _anecdotal_ evidence.

I've found that about 90% of the builds my team and I have created in the past few years have required nothing more complex than what the RC1 dotnet build does.

And what do you expect the RC2 dotnet build or the RTM dotnet build or the post-RTM dotnet build to change in this regard?

Please clarify, I'm not sure what you mean here.

Your argument seems to be (And correct me if I am wrong) something along the lines of "It's not trivial to get dotnet build to do something other than what Microsoft programmed it to do". Which was ok back in the days of DNX because we all liked DNX, but now Microsoft wants to use MSBuild under the hood and you don't like MSBuild, you want the option to change out MSbuild for something else - my point was that this isn't anything new, if you had some issue with DNX then you couldn't change that out either, so whatever your "problem" with dotnet build is, is nothing new and thus I don't think it's relevant to the _actual_ discussion here, which is the structure of project.json moving into .csproj

sigh. My question is: why should dotnet build shell out to MSBuild when msbuild does that really well already? Why have two commands do one thing?

@khellang has already answered this, so I don't particularly want to repeat myself, but that's also because I've already stated quite succinctly what the difference is (I hate quoting myself but I don't think you actually read this):

dotnet build does far more than "just" call the compiler, take a look at the current CLI's implementation of dotnet build. Building one project is just part of the dotnet build process. Eventually _part_ of that process will be to call msbuild but that's not your job, that's the job of the CLI.

So, again, for at least the third time: calling dotnet build is not synonymous with calling msbuild. It is not, as you put it, "two commands do[ing] one thing" and never was. That was never even within the scope of this entire discussion yet somehow you've ended up there.

The real discussion, the one that actually matters is the structure of project.json and how that is to be merged into .csproj. The underlying build system is largely irrelevant if you just want something simple because you'll always just have dotnet build.

So how can we distinguish between what msbuild does vs what dotnet build does now? What are the differences in how they work? I think that is missing in this discussion. Everyone probably already knows, but I think maybe putting it on the table might create some clarity.

@khellang I like the way you expressed it, but then going on from there, I can configure what dotnet test does. I can put a different test runner than xunit's in the project.json, and dotnet test will invoke that test runner.

But yet, from what I have heard about the upcoming changes, there will be no similar capability with dotnet build. It will always use MSBuild to perform it's builds. Is that understanding not correct?

@neoKushan I'm not deliberately antagonising anyone, I am point-for-point deconstructing @shederman's argument

Well at least we now know what you _think_ you're doing. What you're _in fact_ doing is misrepresenting, conflating positions, deliberately misunderstanding things, and generally being a bit of an arse. Your tone is combative, and you're being deliberately obtuse. So much so that I've had to try and break things down into one thought at a time. Which, hilariously, you've misconstrued as changing positions.

@neoKushan Though at this point, I'm not even entirely sure what @shederman's argument even is as we seem to have somehow gone from XML being bad, to MSBuild being bad to now dotnet build is bad.

XML is bad. MSBuild is bad. If dotnet build only uses MSBuild, it's also bad. Please, try and keep up. It's not that complicated. If you weren't being so wilfully obtuse, you'd have grasped it ages ago and been able to actually add constructive input.

@neoKushan This is your "evidence"? Which, remember, you put in bold:

Um no that was my personal experience, not the evidence. My evidence is the 281 respondents out of 383 who believed that the move of .NET Core back to MSBuild is a bad idea. And the 85 of those respondents who believed that MSBuild is fundamentally broken. THAT'S my evidence. Where's yours exactly?

You know, to back up your statement that "... _every single_ Visual Studio .net developer out there would have to disagree"? [Emphasis added]

@neoKushan The real discussion, the one that actually matters is the structure of project.json and how that is to be merged into .csproj

I actually _agree_ with you. BUT the backdrop is critically important. The plan that MS have expressed is that MSBuild will be the centre of the build universe. I don't _like_ that, but let's move on. Given that, there then is a simple question:

"Will MSBuild be the main build system for the .NET Framework forever?"

If so, we only need an msbuild command, and we don't need a dotnet build command, it's utterly superfluous.

However, if we accept that at some point MSBuild may not be the _One True Build System_, then we're in more interesting territory. Then, having a dotnet build makes sense. BUT it's then critically important that we keep that future in mind when discussing merging csproj and project.json.

What I've been trying (perhaps poorly) to point out is that a better (in my mind) option would be to try and keep a clear separation between the _project definition_ files and the _build definition_ files. This would set us up better for a dotnet build that can support multiple build engines. If, instead, we move everything into csproj, then we're locking ourselves into an MSBuild world.

And yes, I do grasp that this "only one true build" situation existed in DNX. But I didn't interrogate that then because I _liked_ the build we had. Ah, the situations we put ourselves in when we blithely accept injustices we _like_ 😉.

So, consider a situation where we have dotnet build able to use one of several build tools, depending on configuration. Just like dotnet test can use one of several test runners. Now, given such an imaginary world, now how would you merge csproj and project.json? That's the discussion I want to have.

@rhires From a very high level dotnet build:

1. Collects the project files
2. Determines if the preconditions are met for an incremental build
3. Reads the project.json
4. Determines the target frameworks
5. For each project:
   
   
   
   1. Build's it's dependencies
   
   
   2. If incremental, checks if a rebuild is required
   
   
   3. Determines output directories
   
   
   4. Collects the source files
   
   
   5. Determines the compile options
   
   
   6. Runs precompile scripts
   
   
   7. Runs the compiler with the source files and options
   
   
   8. Runs the postcompile scripts
   
   
   9. Reports output
   
   

@shederman Thank you! From this point, what would msbuild add/subtract/replace to/from/in this process?

Well at least we now know what you think you're doing. What you're in fact doing is misrepresenting, conflating positions, deliberately misunderstanding things, and generally being a bit of an arse. Your tone is combative, and you're being deliberately obtuse. So much so that I've had to try and break things down into one thought at a time. Which, hilariously, you've misconstrued as changing positions.

Pot -> Kettle

You've changed your position so many times that you can't even keep up yourself, you've argued about literally every single aspect of the build chain, demonstrating that you clearly don't have as good an understanding of how it all pieces together as you _think_ you do, yet _I'm_ being the arse because I dare to point out where your arguments fall flat. I'm still waiting on you responding to half the points I've raised above, but all you do is move on to pick on some other aspect of the build process.

XML is bad. MSBuild is bad. If dotnet build only uses MSBuild, it's also bad.

Nobody other than _you_ has claimed anything like this. Nobody. There's not even the slightest hint that anything of the sort is ever going to happen. I have said to you repeatedly that dotnet build is not _just_ going to call MSBuild, I have said to you that dotnet build and msbuildare not completely synonymous with each other and that dotnet build does a hell of a lot more than call the compiler. I even linked you to the friggin source code and others have came and said the same thing, yet you're still insisting that this is in some way what's going on?

Please, try and keep up.

How about _you_ keep up? Please, show us where you've got this idea that dotnet build will only call msbuild. Who told you that? Where did you read it?

My evidence is the 281 respondents out of 383 who believed that the move of .NET Core back to MSBuild is a bad idea. And the 85 of those respondents who believed that MSBuild is fundamentally broken. THAT'S my evidence. Where's yours exactly?

And you pulled 10% from those figures, did you? Remember, this is your claim:

I would say that MSBuild's power and complexity is fit for purpose for about 10% of builds.

Later you then said:

Funny, I've collected evidence that says something different.

So where's this evidence? I'd love to know how you pulled that figure from your "evidence".

You know, to back up your statement that "... every single Visual Studio .net developer out there would have to disagree"?

Easy: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio hosts MSBuild to load and build managed projects.

If you use Visual Studio to build your projects, you use MSBuild. Even when working with .net core today, even with RC1 VS used MSbuild under the hood. You might not like MSbuild, but like I said nearly every VS developer out there uses it whether they realise it or not.

The plan that MS have expressed is that MSBuild will be the centre of the build universe.

I don't agree with this. They never said that it would be the centre, all they've said is that some parts of project.json would end up going back into .csproj - beyond this, they haven't said a word about to what extent this changes the dotnet build process.

"Will MSBuild be the main build system for the .NET Framework forever?"

If so, we only need an msbuild command, and we don't need a dotnet build command, it's utterly superfluous.

As has been stated many times now, dotnet build and msbuildare two completely separate things. dotnet build does more than just call the compiler toolchain. The purpose of dotnet build is to keep the build process simple for people. See again:

dotnet new
dotnet restore
dotnet build

Even if msbuild becomes a core component of the dotnet CLI, that doesn't change the fact that dotnet build is the clean, simple wrapper around what is (and always will be) a fairly complex system. Hell, half the reason the dotnet CLI exists (And DNX before it) is specifically to get away from the command-line argument hell that MSBuild ultimately is. Your argument is a bit like saying "Why do we need an npm install command when I can just curl the package?". Sure, you can do it all manually if you really want, but you gain almost nothing from it. So what if dotnet build uses msbuildunder the hood? You'll almost certainly never see it, or need to know about it.

You can't compare your old experience with MSBuild, it's utterly different. We've all (seemingly) been burned by that one because we're used to opening VS, creating a project and having it just build, but then when you go to have that same project build on a build server it's suddenly complaining about shit that should _just work_. Probably one of the best things Microsoft did with TFS 2015 was create a build definition that ties into _Visual Studio_ rather than _MSBuild_ because you're back to it "just working". That's exactly what this build toolchain is - dotnet buildis not meant to replace your entire build system, it's only concerned with building your projects, even if it does use MSBuildunder the hood. If you want to use something like TeamCity or Jenkins, dotnet build is all you have to tell them to call and dotnet does the rest. _How_ it does that isn't any concern to you.

The only thing - and I mean this completely, the only thing that actually changes for you is the project.json/csproj file. That's _it_. That's why all this arguing about what dotnet build really does and what MSBuildis good and bad for is absolutely _pointless_.

@neoKushan just stop...

@neoKushan just stop...

Part of me likes to imagine the ASP.NET team deliberately cancelling the standup because they were enjoying the show, and providing answers would bring it all to an end. :smile:

From my (now firmly) agnostic position, both sides have seemed to be willfully obtuse to the other's points for some time now. You are succeeding in setting my mental image of the .NET Core community as nonconstructive and worse. Talk about perception...

Most of the non-NuGet stuff will get merged to csproj. What will happen to NuGet stuff if there's no project.json (nuget.json?) ?

provide a way for users to manage their dependencies the way they like, and maybe provide a dotnet nuget by default since NuGet is well established in the .net community.

but do not hard couple all the dotnet core stuff to that sole way to manage dependencies (dotnet restore shouldn't be equal to dotnet nuget restore), for many people nuget is only a package repository but not a dependency manager, people do have other choices that they might find more productive / suitable for "dependency manager" use case.

Will we be keeping the IntelliSense for dependency management? This is basically one of the best demo features we have for project.json.

you can repurpose the logic, I don't see this as a big deal, for example, I go on nuget.org and do a search for a package and copy the id from the url, it's efficient.

You might want to provide shell completion also, that will buy you lots of admiration from people using bash or zsh:

dotnet nuget add S[tab] provides completion list for project identifiers starting with S

having intellisense in msbuild *proj files should be doable too if you want to bake a <NuGet> tag there, but same, do not hard couple nuget to the whole eco-system, i.e. <Package>NuGetPackageId</Package> shouldn't equate to <NuGet>NuGetPackageId</NuGet> OR there should be a very simple (and extremely well documented and supported) way to override this.

Paket Visual Studio plugin do have autocompletion on nuget, it works but is kind of slow anyway because I assume it takes some time to return the response from nuget.org.

Are we keeping the JSON format for dependency management? XML is horrible for those kinds of things (see Maven). JSON is hands down simpler to represent those dependencies.

If you are looking for ideas for format, you can look at paket.dependencies, otherwise, I don't think it matters much, editing the project.json was roughly as nice as editing packages.config in terms of dealing with NuGet, do whatever is convenient for users that choose NuGet as a package dependency manager (which is not 100% of users and don't have to)

As a side note, if you still need a lock file, could you make it user readable, something that get checked in the repository, and easy to make diff of?

@rhires From this point, what would msbuild add/subtract/replace to/from/in this process?

Well, that depends on how they integrate it. If they do a "hard lock", integrating msbuild deep into dotnet build, which the public info appears to indicate is their preferred approach, then it would be replaced in it's entirety by msbuild.

However, if they make dotnet build configurable, I expect it'd work something like:

1. Collects the project files
2. Reads the project.json
3. Determines the target frameworks
4. Determine the build tool to use
5. Shell out to the build tool
6. Reports output

@neoKushan That's why all this arguing about what dotnet build really does and what MSBuild is good and bad for is absolutely pointless.

👍

What I want to _discuss_ is what project.json and csproj should look like in a world where dotnet build can shell out to MSBuild as one of _many possible build tools_. Is that okay? Can we talk about what would be in project.json vs what would be in csproj, given that?

Because if we _can_ discuss that I believe this thread can actually become constructive.

@jmm You are succeeding in setting my mental image of the .NET Core community as nonconstructive and worse

Sorry about that. However, if you have the time, I would suggest reading through some of the chat archives of some other huge open source projects.

Arguments are actually a sign of a healthy community, just like in life. When everyone follows a set of leaders blindly, well, things are normally not so good. Decisions, evidence, and decision making should be open to interrogation.

@shederman In the interests of continuing a productive discussion, I would also like to draw a line to discuss the implications of the proposed changes.

I think that the core discussion here should be on the layout and format of the "new" .csproj and what happens to project.json (Or to be specific, the "project" structure as a whole). I don't think the build system, whether it's msbuild or not, how dotnet build works, etc. is within the scope of _this_ issue. That's not to say that discussions on that are unwelcome or invalid, just that they don't belong in this _specific_ issue, rather they should be separate issues. As any experienced developer can attest, it's very frustrating when a bug report contains multiple, separate bugs and usually the first thing you'd do is split them up into multiple issues to track - I think that's really what's missing here.

From my own _personal_ perspective, I don't care what the build system is or how it works. I don't mean that to sound ignorant or dismissive to those who do, I mean that from a developer perspective, I just want to know that "dotnet build" spits out my assembly as long as the project structure is correct - so as far as I am concerned, dotnet build -> Project -> -> Assembly. The only thing that truly matters to me, and what the scope of this discussion should be (And I think we are finally in agreement here) is what that project looks like and what it means to my daily workflow.

I don't want to deal with merge hell just because I added a .cs file, nor do I want to deal with a thousand line long XML file just because some system that _I don't care about_ depends on it - I don't think any of us do and that has been a bugbear of VS development for years now. We had a glimmer of hope with the project.json format as it stands today because it was _so much better_ than what came before, so I completely understand and get why tempers frayed so quickly at the mere hint that we'd be going back to the "bad old days", but at the same time it's worth stating that we shouldn't kid ourselves - project.json today is by no means _perfect_, it has its own set of issues and while they may be minor in comparison to the issues of "old" csproj, it's worth being objective and discussing where things could be improved and what could be better.

There is definitely a _best of both worlds_ possibility.

I think that the core discussion here should be on the layout and format of the "new" .csproj and what happens to project.json (Or to be specific, the "project" structure as a whole).

You know, it's been mentioned a few times in this thread, but I thought I would mention it again, just to share my own "personal aha" this morning, but there is a whole other effort under way with the Roslyn-based Project System -- or to be more accurate from its readme the Central Project System (CPS). Browsing through its documentation it does appear to be more of a project definition effort than process. Maybe this is where all the magic between .json and .csproj is being consolidated? And then MSBuild will be relegated as a process endpoint? Wouldn't _that_ be nice. :smile:

Anyways, I've started/watched that repo to start getting updates on what's happening there. :+1:

(I'm also halfway wondering if we should move this discussion to a new issue there.)

@neoKushan Definitely, the fact that there is msbuild involved is not problematic by itself. And I think there is a path forward that would allow us to keep simple human readable/editable file formats while harnessing the power of msbuild.

What worries me, is arguments like "msbuild is battle tested", regular msbuild is but the current xplat does not seems to be. When we look at issues on the related github repo, it's not quite there yet. In addition, msbuild team already said that supporting new/improved serialization format is not going to be a target for msbuild but rather for a new build system (which won't happen anytime soon).

I'm also worried when people assumes that what we do is just adding removing dependencies. Maybe it's what they do because they are just doing 'hello worlds' apps. But other options like buildOptions and overrides by moniker are extremely powerful and handy. Not to mention that current json schema based editor experience is just awesome.

One path could be to have an msbuild task which would load project.json as an alternative. Then, let developer choose in the project settings if they want to enable project.json which would add that task to the csproj.

@Mike-EEE Yes there is hope :)

I'm pretty sure that the current leaning is to have project.json become nuget.json - which would hopefully resolve the dependency issue and leave most of the existing project.json functionality in tact.

The only thing I can't figure out is how this affects multitargeting, would the csproj and nuget.json have to be aware of and understand what they're each targeting? Do we end up with a csproj for every target (yuck!), or can they extend .csproj enough to account for it?

project.json become nuget.json

Just curious here... where is _this_ conversation happening? I have gotten on the nuget team before for locking in with a particular format. In regards to project.json they said that was a Visual Studio tooling concern and something they couldn't address. Now it seems the dynamics have changed and have copy/pasted more of the same kind of problem. :stuck_out_tongue:

To clarify my concern, it is that we are now mixing JSON and XML together which produces inefficiency at the very least.

Just curious here... where is this conversation happening?

Well it was originally stated here: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

Its possible that the project.json file remains, and contains all of the package references for NuGet and is renamed to nuget.json.

And I think this is really what the discussion here is about, how much do you take out of project.json and put into a .csproj? In my projects, the majority of project.json has been package references, particularly if I am targeting multiple frameworks. The above suggests that all of this would remain and only the "other" bits would be taken out. In my (again: Personal) experience, these "other" bits really don't change much through the life of a project, so even if it's in XML it's not a lot of XML and it should be fairly static...one hopes.

I do agree that mixing and matching XML and JSON for different configurations is a bit smelly, but then I am somewhat biased against JSON as I'm not a huge fan of how it's being used. That's definitely personal preference, though.

Well it was originally stated here...

Ah yes... of course! OK. Just making sure. Hopefully tomorrow will be the day we finally get some clarity (for better or for worse!) around this.

I do agree that mixing and matching XML and JSON for different configurations is a bit smelly

Really glad I am not the only one who sees this and feels this way. :) It seemed lonely there for a while as I first battled the grief of seeing .JSON creeping into projects. Totally makes sense from a web-appdev background, but the native appdev no likey, and vice versa when it comes to XML.

Haha... speaking of which, writing the above made me pull out the ol' archives. Here's me back in 2014 making the case for (yep, you guessed it!) Xaml instead of JSON hahaha oh look at how young and completely naive I was! So cute and unassuming! Boy, did I have the world to learn. :stuck_out_tongue: But, I will say that there has been SOME progress. We did get rid of that .ini used for the web server configuration, after all. :smile:

@neoKushan There is definitely a best of both worlds possibility.

👯 👯 👯

@neoKushan I'm pretty sure that the current leaning is to have project.json become nuget.json...The only thing I can't figure out is how this affects multitargeting, would the csproj and nuget.json have to be aware of and understand what they're each targeting?

Using the project.json schema as a starting point, from my perspective the following items should probably _not_ be in the build definition file:

• List of source files
• Project dependencies
• Target frameworks
• Project commands (e.g. web, test, etc)
• Webroot
• Metadata
• Language version

The following I don't _believe_ should be in the build definition file, but I'd be _meh_ about it if they were:

• Configuration definitions
• Scripts, pre and post

The following probably _should_ be in the build definition file:

• Compilation options (excluding language version)

The above is just to provoke discussion. Happy to debate any individual points. Suggest ignoring what the files are called and what format they are for now.

@shederman Do we need to clarify what you mean by "build definition"? Perhaps my terminology is off, but I wouldn't call the current project.json a _build definition_ file but rather a _project definition_ file (and the same would go for the new csproj file). Possibly semantics, but to me a build definition suggests it defines _how things are built_, whereas a project definition defines what makes up a project and leaves build steps to something else.

_This is my project, it consists of these items and has these dependencies. How you build it is none of my business._

A lot of the project can be determined just through convention, like how the assembly name comes from the top level folder. Going along this line of thinking, _nuget.json_ would just be anything to do with nuget - so packages/dependencies would go in there and I think we're all happy with that.

What I can't quite decide on is target frameworks. If Nuget.json is only concerned with dependency resolution, then although it might have some separation for references when targeting different frameworks, I'm not entirely sure it should be the one deciding which frameworks are actually targeted, that seems something more for the _project definition_ (Whatever that ends up being).

Then again, there's more to nuget than just package references, it also contains the package _definition_ and version as well for when your library _becomes_ a nuget package. It seems somewhat as though nuget.json is then doing at least two different things and that's starting to smell a bit. Perhaps (just spitballing here), the csproj would define the details of the package, the target frameworks etc. and each target framework could point to a .json file, which is basically the nuget packages. In other words, instead of one nuget.json, you'd have a separate .json file for each framework. That might be a terrible idea, I've not especially thought it through.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/:

We had two choices. One was to move all .NET projects to use project.json. This would require us doing tooling work that touches all of the project types in Visual Studio, Xamarin and our partners like Unity. We would have to expand project.json to support all the build scenario’s required by each of these project types and provide a migration story . Another choice was to build bridges so an .xproj project can reference a .csproj project and a .csproj project can reference an .xproj project in Visual Studio and Xamarin Studio. The bridge has challenges as well, for example when a customer creates a project they would now have to choose an .xproj or a .csproj, which just adds more choices and complexity.

And

After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system.

We plan to enhance .csproj to support the missing functionality:

• No listing of files in the project system
• CLI tool for doing any operations on the project file, for most scenario’s you would not edit the file
• Build packages directly from the project
• Multi-targeting

And because all of the .NET uses the same tooling we can then look at enhancing MSBuild. We will solicit feedback from customers and the community on supporting JSON instead of XML, having our tooling not generate overly verbose files and more. And because everything uses the same tooling, these enhancements could work on all .NET projects.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment-71485:

Assuming that .csproj still means C# Project, there will of course be other targets for non-C# projects, correct? [Ben]

Yes. [Scott H]

I'm a bit afraid that .net will be stuck with a complex-legacy-justForTooling build system as msbuild, maybe we should start with it to get dotNetCore going and then plan for a new modern build system ?
To give every body hope and do things without rush of shipping .netcore.

I do not frequently need to edit msbuild files, but when i need it's very difficult, the declarative approach make you lose yourself in the flow, i bring my example, nobody seems to be able to solve simple problem like this https://github.com/madskristensen/BundlerMinifier/issues/89
If after 6 months nobody could run a task (two different tasks each not knowing about the other one) after another without dirty hackings or in an additive way maybe there is something to fix over there.

Thanks

CLI tool for doing any operations on the project file, for most scenario’s you would not edit the file

:-1:

I'm all for CLI tools to help you do your job, but if I _have_ to use a CLI tool to manage references and packages, I'm going to be upset.Install-package is great, but being able to just type out half the package name and have it pop up a list of possibilities, with all their versions, was amazing.

cli tools are great for automation but are a poor way to perform tasks except for basic ones like npm install or dotnet restore. If we have to learn things like dotnet buildoptions define add --framework net451 SOME_DEFINE it definitely sucks hard. This is a huge loss.

A good developement story is :

• Easily editable project and build files
• Configurable build system
• Simple, well designed and complete cli tools
• Great Gui, IDE tools

Making one of those poor (which was actually great before) to make one other acceptable is just stupid.

The unity and xamarin argument is quite bad actually. I don't think they'll move to .net core that soon, and going backward for their convenience is just lame when designing for the future of .net.

And because all of the .NET uses the same tooling we can then look at enhancing MSBuild

No MSBuild be enhanced before we are forced into it...

This article is really not the blog post we where waiting for and it confirms that .net core is being misguided there.

cli tools are great for automation but are a poor way to perform tasks except for basic ones like npm install or dotnet restore.

Again I feel this issue is a clash of cultures/preference/philosophy. Somewhere along the way CLI became a good idea to replace GUI, when really you need both as you will find developers (once again) have their preference of approach. Some innovation is certainly required in this area, as it seems it constantly is an issue: CLI is created, but GUI isn't and vice versa.

To me it seems like a framework of sorts is needed to create the API and then the CLI and GUI versions are created automatically for you.

We could call it... CLIGUIAPI! :+1: :+1: :+1: #problemsolved

this issue is a clash of cultures/preference/philosophy

Definitely and this is one you can't solve except for addressing each approach with the best approach possible. node.js and I'm not the biggest fan of this stack did a great job at this having the great cli tool npm and package.json. The Gui part is addressed by various vendors (webstorm, vs code, visual studio). Fancy build systems like gulp are one hundred percent optional.

maybe I'm a minority on this and maybe not, but while I do like project.json, the reasons explained here https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ make a lot of sense to me. I feel pretty confident that we will end up with a good experience so I'm really not worried about this and it in no way diminishes my enthusiasm for these new frameworks. People seem very quick to get out the pitch forks and act like it is the end of the world before even seeing what the final experience will be

I've stopped reading a while ago but I'll close this issue as soon as we have a definitive answer about project.json.

How about keeping both project.json and .csproj, where .csproj is generated by the command dotnet restore and not synced in version control by default? The difference will be, instead of dotnet restore generating “project.lock.json” (and do other things), it will generate (or update) the “.csproj” file. Even both “project.lock.json” and “.csproj” can stay as both are being auto generated. Flags can be used in dotnet restore for generating .csproj. In the announcement, Microsoft is already saying- “CLI tool for doing any operations on the project file, for most scenario’s you would not edit the file”. IMHO, dotnet restore is most suited to be THAT CLI tool, which will take project.json as an input. The upsides will be-

• Both formats of project.json and .csproj can stay unchanged. That means new generated .csproj will be compatible with earlier versions of Visual studio and other tools. dotnet restore can insert explicit "include" list of project files in the .csproj file.
• As .csproj is being auto generated and not in version control, developers do not have to deal with hand editing and merging .csproj.

Yeah... no.

Closing. Everything that could be said has been said.

If you want to work out how it should be made and be in the design team that talks about it... please do.

Otherwise, it's wasted space and especially... it's filling inboxes.

@MaximRouiller hope you'll gather the comments that focus on answering your initial questions despite the amount of noise.

posted yesterday:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan Do we need to clarify what you mean by "build definition"? Perhaps my terminology is off, but I wouldn't call the current project.json a build definition file but rather a project definition file (and the same would go for the new csproj file). Possibly semantics, but to me a build definition suggests it defines how things are built, whereas a project definition defines what makes up a project and leaves build steps to something else.

Pretty much spot on my thinking. Project definition would be a purely declarative description of what the project is. Metadata, versions, filespecs, etc. Build definition would be the steps that are performed in order to convert the project into executable code. Build definition would almost certainly need something quite rich to express it, my favourite being code.

But, it all seems moot: @MaximRouiller and MS have closed everything down. Your feedback has been ignored and killfiled, thanks for calling.

Overall, the whole csproj -> project.json -> csproj thing was a set of bad decisions which will come back to haunt MS in .NET adoption IMHO. The trend of devs abandoning .NET for greener pastures will continue unabated.

So sad.

@shederman There is no correlation between a declining Tiobe index for C# and the decision to switch back to csproj. Also a declining Tiobe index is not an indication of the declining health of the C# ecosystem. More languages entering the market make it hard for any one language to maintain a large market share.

I'm not clear on the impact as a whole, but I would point out that there should be a separation of concerns evaluation here. If csproj means just because I'm adding a file, my team mates are concerned about other impacts related to the build process, then we're missing the boat.

csproj is something I tolerate, not prefer.

@jerometerry I wasn't saying this in itself will cause a decline. But many of the innovative changes in .NET Core were aimed at arresting the decline, and the losses to AWS. These changes are being slowly chiselled away one by one, and thus .NET Core is becoming more and more unlikely to entice developers to the platform.

In addition, the poor decision making - that can be traced right back to the decision to introduce project.json right through to today does not bode well.

If MS are determined to focus on the past, they should not be surprised when they lose out in the future. The thinking that got you into a problem is unlikely to get you out of it.

More languages entering the market make it hard for any one language to maintain a large market share.

True, but in my experience more damage than necessary in .NET is caused by friendly fire.

BTW... was there even a standup yesterday? I signed into live.asp.net but the countdown just reset, with no video/feed or anything...

@Mike-EEE They heard you were coming :stuck_out_tongue_winking_eye:

Frustrating that they did this. I blogged about it: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

From today's standup: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

He specifically addresses project.json here: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Although the project.json format is far simpler to edit (unless you're at that stage of .NET dev of being a drag and drop dataset-monkey), the biggest problem for me is nobody is bothering to update their libraries to the .netcore. So far I've managed to get one branch of Restsharp working, but this uses the project.json format. JSON.NET, Structuremap, NUnit etc. etc. all have stale DNX branches where it looks like the developers abandoned hope.

So it's a bit strange to call the .NET Core RC1/2 a release candidate when the project format the dotnet command line tool is being removed. That to me is still beta or even alpha software as it's experimental.

My main motivation for moving to vNext is to make use of cheap Linux hosting, and Docker. A project migration tool ASAP would be wise as most people will be completely handicapped by their libraries via nuget references missing .NET Core versions.

@yetanotherchris dnx was a concept in rc1, it changed to dotnet cli in rc2, so most dnx projects or branches would be stale at this time

project.json is still here and needed for rc2, discussion about it going away in the future after RTM

json.net aka newtonsoft.json does work and is used by the framework itself, I use it in my projects too
nunit is not compatible, everyone uses xunit afaik
structuremap does have and rc2 compatible library

there are still lots of 3rd party things not yet ported to rc2, but Microsoft does not control the timing of other projects and when they will make compatible libraries

@yetanotherchris If you use imports in your project.json, you can specify the old, non-netstandard monikers and it'll use them:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

It's probably for this reason not many people have bothered updating their libraries just yet, there's no need to hit another moving target before the actual RTM.

@joeaudette I was talking about the branch name (DNX) not the command line tool dotnet. A lot of people use NUnit, it's pretty much the defacto testing suite outside of MsTest. I'm not sure where you're finding the JSON.NET or Structuremap packages from, there's an unofficial version of Structuremap called DNX and a Newtonsoft branch here and a .NET Standard 1.0 beta on nuget.org (.net standard is now redundant as far as I know).

@neoKushan thanks, I'll look into that.

I think my main point was it's a bit silly calling it a release candidate as it's going to completely change for the final version. Maybe in a month we'll get a flury of activity now the build systems aren't completely different from the old and new - although as someone who is primarily a web developer I'd much prefer project.json.

@yetanotherchris

(.net standard is now redundant as far as I know).

What makes you say that? Netstandard isn't going away with the project change, it's here to stay. You'll be able to target netstandards in your future csproj files. Netstandard is absolutely essential. One of the main reasons they're ditching project.json is to unify the entire .net ecosystem and that's what netstandard is also bringing to the table.

I think my main point was it's a bit silly calling it a release candidate as it's going to completely change for the final version.

I agree to an extent with this, though I don't think it's changing as much as people think it is. For a start, project.json is still going to be here for the RTM, all the changes will happen after that. You might then ask why call it "Final" if it's going to change and there's perhaps a point there, but ultimately all of your code and libraries and all that isn't changing, it's just the project _definition_. That's not as big a change as one might initially think, though there's definitely going to be some migration fun to be had.

@yetanotherchris you have to remember that rc2 is preview and so you have to look for preview packages from 3rd parties also
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

I don't know about NUnit if it will be supported later but for now on .NET Core and ASP.NET Core projects people are using xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris I think we can all agree that rc1 should have been labelled beta9, rc2 is the first real rc quality release
project.json and such is tooling not part of the framework per se, tooling will remain preview and subject to change for a while even when the framework is RTM

I would not even be surprised if we even bring back- maybe we do keep a project.json, and it only works in limited scenarios. If that's what people want, we'll entertain that idea.

Scott Hunter, dotnetConf 2016 Day 1 Keynote 12m24s

Does anyone know if Mr. Hunter is on GitHub? And monitoring the chatter in the product forums? From the sounds of it, he is missing out on the feedback here.

As the program manager for .NET and Visual Studio, I doubt @coolcsh honestly has the spare time.

I'd be quite horrified if he's unaware of the feedback that's been given. Maybe not all the details, but certainly that there's been significant pushback.

Here's your chance everyone:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

I put a dollar in the tip jar, so to speak. :stuck_out_tongue:

tugberkugurlu may have been on to something with the comment "suddenly, dark matter enterprise developers started giving feedback behind the closed doors". Another way that could be put is, "our enterprise customers raised some valid concerns about compatibility, and their current investment in our products". While the 'community' appears unhappy to not be the lion's share of say in, well, everything, enterprise customers carry a pretty big stick: they pay lots of money for access to platforms, tooling and support. Their concerns are not going to be ignored, nor should they be. In the end what MS appears to shooting for is enabling the maximum number of devs build what they want to build, easily, and they also want to try to enable interoperability and sharing along just about every definable domain. They are promising to make csproj be much easier to work with and much more capable. So, now, they're up to bat to deliver on that.

As I've said many times, I'm an enterprise developer at a major bank, an enterprise customer. WE weren't consulted about these changes. So WHO exactly were the "dark matter enterprise developers"? That information is apparently top, top secret. 007 level stuff.

It's all well and good asserting that enterprise customers carry a big stick, but apparently it's only SOME of them that get to do so. Which ones? Based on what criteria? How do we get into that privileged list? What partner level is it? What annual spend? Inquiring minds want to know how much EXACTLY we need to be paying MS before they actually listen to our opinions?

@shederman are you an enterprise mobile dev, or enterprise UWP dev? Or Enterprise Unity Dev?

None of the above. We write core systems for asset management and bank integration. Some Online stuff too.

@shederman I suspect that might be why you weren't asked?

Please clarify?

Are you really saying that the only corporate devs MS now supports are those doing mobile work for 1% of the market, UWP apps for um, the 5% of users who care, and game development? Out of the entire spectrum of development, MS is turning their back on everything but that?

Umm. No.

I'm saying that the changes came about after talking to _those_ groups, so that's why you weren't asked. Microsoft has to support all of their developers, not just the asp developers.

Yes, so if they're going to support all their developers, maybe they should talk to all the developers. Maybe just talking to a selected subset 5% of enterprise developers is not a good way of gauging the opinions of enterprise developers as a whole.

So, to get a large bank's opinion listened to, we must switch all our development to UWP/Unity/Mobile?

That's ridiculous.

maybe they should talk to all the developers.

Isn't that what they've been doing for the last 2+ years?

@shederman So just because _you personallly_ weren’t asked, you are implying that nobody else who covers your development range was involved?

Also, stop making up those numbers – _that_’s ridiculous.

@poke I'm asking who WAS involved? I'm saying that I've heard enterprise dark matter developers were consulted, and pointed out that I'm at bank, and we weren't, so who exactly was?

I actually thought the numbers were quite generous, but okay.

@shederman I think you're looking too much into this whole thing. The focus for the last 2 years has been squarely on the asp.net side of things, but as word of .net core started to spread, a lot of people started asking "How can I use this?". It wasn't some back room deal, it was people asking for literally years. You only have to look around to see many people wanted more from .net core.

There is also the matter of actual enterprise support requests from big organisations wanting to know how to port their existing stuff over to be cross-plat - you probably weren't "Asked" because you didn't require someone from Microsoft telling you that what you are trying to do is beyond the scope of the project.

Another way to look at it - and the way I personally view it - is you have been asked, you were asked the second the announcement was made months ago. For all the cries of people saying decisions were made without consulting anyone, Microsoft has repeatedly stated that they're still working out details, that they still don't have the final pieces put together and now is the time to voice your opinion. Scott Hunter even said that if people _really_ want project.json as an option, they'll consider keeping it. Go watch the dotnetconf keynote if you don't believe me.

@neoKushan I appreciate that Scott stepped back a bit saying that they would consider keeping it, but there really needs to be a single, centralised point for people to express that this is what they want otherwise the project.json issue will keep popping up in discussions everywhere. It also means then that when it is brought up everyone can reply with the same "hey, they'll consider keeping it if developers really want it, here is where you go to let them know".

project.json was a good step. But it was naive in my opinion. It doesn't take into cognizance that people would want to have hybrid projects written in C++ or F#. Some of their early design decisions like dnx and using nuget as the unit of assembly were not feasible for the dotnet ecosystem as a whole. What you are seeing is that in the process of bringing harmony to dotnet, they have to make these tough choices.

Forking and Re-inventing in my opinion will not help the dotnet ecosystem it will only hurt it. Node and Go (especially Go) are very attractive to beginners because they have homogeneous and consistent platform/tools.

I find the whole XML vs JSON argument silly because in another 5 years, it will be JSON vs YAML and after that YAML vs Groovy(e.g. gradle). XML is not as evil as you all make it out to be. MSBuild is very matured and has a lot of investment in it that will benefit everyone.

That said, A LOT of work needs to be done with MSBuild to make sure you can get either the same or at the very least a less painful way of using and editing csproj files. Then move the nuget dependencies to a nuget.json file. Make use of Convention over Configuration so that if you are on the "happy path", your csproj will be almost empty, a bit like web.config today. and then have cli options that tweak the csproj

For me, I will miss project.json but not for the reasons you think.. C# projects will be fine. I'll miss it because of F# I prefered editing project.json for the compile ordering rather than editing msbuild. Again not because xml is evil but because fsproj files have a lot of bloat brought about by msbuild

My issue with this decision was primarily the way the csproj file was less about xml/json and far more about what they chose to include in the csproj file. It contained project definition, it contained IDE settings, it contained build steps, it contained references...

There isn't a lot that _didn't_ end up in that thing. This made it terrible and is only compounded when having to deal with msbuild being fairly arcane at times. If you're honestly interested in make .NET Core good and not just work make the project file agnostic to build tooling. I should be able to specify what my project is and what it depends on separate from how to build it. Not to mention this starts to allow us the choice of tooling, even if the initial option is just backed by msbuild right now.

I agree with this. At the end of the day, the key issue with csproj is that
it does everything.

I like the middle ground PatriotBob is suggesting...

On Tue, Jun 21, 2016 at 1:28 PM PatriotBob [email protected] wrote:

My issue with this decision was primarily the way the csproj file was less
about xml/json and far more about what they chose to include in the csproj
file. It contained project definition, it contained IDE settings, it
contained build steps, it contains references...

There isn't a lot that _didn't_ end up in that thing. This made it
terrible and is only compounded when having to deal with msbuild being
fairly arcane at times. If you're honest interested in make .NET Core good
and not just work make the project file agnostic to build tooling. I should
be able to specify what my project is and what it depends on separate from
how to build it. Not to mention this starts to allow us the choice of
tooling, even if the initial option is just backed by msbuild right now.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment-227511911, or mute
the thread
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

The whole XML is bad, JSON is great hoopla was heavily over hyped. I like what PatriotBobo is saying.

managing a s/w project entirely from npm's package.json has never so simply and concisely made declaring my project, building my project, upgrading my project (e.g. greenkeeper), read/writing/parsing data about my project, and publishing my project so easy. _so_ easy. as many of us, my history is in c++/java/python/node, with play in others. i long for the npm experience in all of my projects now.

the project.json promised to yield these same characteristics. i think it's a model worth emulating, and not sacrificing the simplicity and power.

if the team .net core team thinks the other solution can provide these traits, excellent, and power to 'em! however, please don't undermine the beauty in the simplicity as you progress.

also, i understand that i'm just noise by this point in a giant thread. maybe the moderators ought consider closing it and handling the ordeal in more controlled fashion. lots of good feedback. maybe a little trolling too :$ :)