[Discussion] Project dependency after project.json phase out #1433

Closed
MaximRouiller opened this Issue May 11, 2016 · 338 comments

Projects

None yet
@MaximRouiller
MaximRouiller commented May 11, 2016 edited

After the last community standup, there was an announcement about the phasing out of project.json.

Here are a few issues I see with that and would love some clarifications.

  • 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?) ?
  • Will we be keeping the IntelliSense for dependency management? This is basically one of the best demo features we have for project.json.
  • 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.

Is it possible to have some clear response to those questions?

Thank you,

@darrelmiller

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

@shawnwildermuth

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.

@sandorfr
sandorfr commented May 11, 2016 edited

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

@darrelmiller

@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.

@sandorfr
sandorfr commented May 11, 2016 edited

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.

@tugberkugurlu
Member
tugberkugurlu commented May 11, 2016 edited

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.

@shederman

+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.

@cwe1ss
cwe1ss commented May 11, 2016 edited

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.

@imranbaloch

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 :(.

@cwe1ss
cwe1ss commented May 11, 2016

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.

@sandorfr

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.

@julielerman

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!

@shederman

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.

@cwe1ss
cwe1ss commented May 11, 2016

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.

@JulianRooze
JulianRooze commented May 11, 2016 edited

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.

@shederman

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

@shawnwildermuth

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.

@ejsmith
ejsmith commented May 12, 2016

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.

@MaximRouiller

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

@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

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.

@MaximRouiller

@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".

@dustinmoris
dustinmoris commented May 12, 2016 edited

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.

@shederman

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%

@dustinmoris

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.

@shederman

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?

@shederman

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!

@dustinmoris

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.

@smbecker

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.

@shederman

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?

@dustinmoris

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.

@shederman
shederman commented May 12, 2016 edited

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.

@shederman

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.

@rhires
rhires commented May 12, 2016

@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.

@shederman

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.

@abcplex
abcplex commented May 12, 2016

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.

@darrelmiller

@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.

@abcplex
abcplex commented May 12, 2016

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

@GuardRex

@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."

@MaximRouiller

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.

@dustinmoris
dustinmoris commented May 12, 2016 edited

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.

@shederman

@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"

@abcplex
abcplex commented May 12, 2016

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.

@GuardRex

@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.

@dustinmoris

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

@darrelmiller

@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.

@MaximRouiller

@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.

@ejsmith
ejsmith commented May 12, 2016

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.

@iamkoch
iamkoch commented May 12, 2016 edited

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.

@JuergenGutsch

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.

@neoKushan

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.

@sandorfr

@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...

@shederman

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.

@neoKushan
neoKushan commented May 12, 2016 edited

@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.

@abcplex
abcplex commented May 12, 2016

@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

@neoKushan

@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.

@abcplex
abcplex commented May 12, 2016 edited

@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.

@neoKushan
neoKushan commented May 12, 2016 edited

@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.

@lokitoth

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
@lokitoth

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.

@shederman

@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.
@neoKushan
neoKushan commented May 12, 2016 edited

@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?

@shederman
shederman commented May 12, 2016 edited

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]

@lokitoth

@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)

@shederman

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.

@shederman

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.

@darrelmiller

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

@rhires
rhires commented May 13, 2016

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.

@knarfalingus
knarfalingus commented May 13, 2016 edited

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

@shederman

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.

@knarfalingus

@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.

@shederman

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 :-)

@shederman

@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.

@neoKushan

@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.

@neoKushan

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.

@michaelvolz

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.

@bzbetty
bzbetty commented May 13, 2016 edited

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.

@shederman

@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?

@shederman
shederman commented May 13, 2016 edited

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?

@colhountech

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

@StephenRedd

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. .

@shederman

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?

@sandorfr
sandorfr commented May 13, 2016 edited

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.

@Mike-EEE

LOL @shederman what have you pulled me into now?! 😄 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 ❤️ my Xaml!). I have an open discussion on MSBuild's repo here (Microsoft/msbuild#613) in regards to this and also on Roslyn's project system (dotnet/roslyn-project-system#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. 👍

@Funbit
Funbit commented May 13, 2016

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...

@sandorfr
sandorfr commented May 13, 2016 edited

@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.

@CodingGorilla

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.

@MaximRouiller

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

1ajq1

@Mike-EEE

That blew way out of proportion than what was initially intended

@MaximRouiller do you even developer, bro??? 😄

@MaximRouiller

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

@lokitoth

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.

@darrelmiller

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

@Mike-EEE
Mike-EEE commented May 13, 2016 edited

@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. 😆

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. 😛 Back to our regularly scheduled slugfest!

@Mike-EEE
Mike-EEE commented May 13, 2016 edited

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? 😛

@CodingGorilla

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? 😛

@Mike-EEE Yes, I think you are. 😉

@darrelmiller

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

@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.

@darrelmiller
darrelmiller commented May 13, 2016 edited

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?

@shederman

@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.

@MaximRouiller

@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.

@MaximRouiller

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.

@shederman

@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.

@neoKushan

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.

@poke
poke commented May 20, 2016

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.

@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. 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.

@laskoviymishka

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.

@shederman

@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.

@shederman
shederman commented May 20, 2016 edited

@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.

@shederman

@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.

@neoKushan

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

👎

@shederman

@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.

@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.

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?

@sandorfr

@neoKushan please stop antagonizing him. this is not constructive.

@shederman

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.

@michaelvolz
michaelvolz commented May 21, 2016 edited

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." 😞

Like I said, perception matters.

@khellang

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 😉)

@neoKushan

@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.

@rhires
rhires commented May 21, 2016

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.

@shederman

@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.

@shederman

@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
@rhires
rhires commented May 21, 2016

@shederman Thank you! From this point, what would msbuild add/subtract/replace to/from/in this process?

@neoKushan
neoKushan commented May 21, 2016 edited

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.

@sandorfr

@neoKushan just stop...

@Mike-EEE

@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. 😄

@jnm2
jnm2 commented May 21, 2016

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...

@smoothdeveloper

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?

@shederman
shederman commented May 23, 2016 edited

@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
@shederman

@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.

@shederman
shederman commented May 23, 2016 edited

@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.

@neoKushan
neoKushan commented May 23, 2016 edited

@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.

@Mike-EEE
Mike-EEE commented May 23, 2016 edited

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. 😄

Anyways, I've started/watched that repo to start getting updates on what's happening there. 👍

(I'm also halfway wondering if we should move this discussion to a new issue there.)

@sandorfr
sandorfr commented May 23, 2016 edited

@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 :)

@neoKushan

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?

@Mike-EEE

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. 😛

To clarify my concern, it is that we are now mixing JSON and XML together which produces inefficiency at the very least.

@neoKushan

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.

@Mike-EEE

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. 😛 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. 😄

@shederman

@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.

@neoKushan

@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.

@jnm2
jnm2 commented May 24, 2016 edited

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]

@valeriob

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 madskristensen/BundlerMinifier#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

@neoKushan

CLI tool for doing any operations on the project file, for most scenario’s you would not edit the file

👎

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.

@sandorfr
sandorfr commented May 24, 2016 edited

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.

@Mike-EEE

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! 👍 👍 👍 #problemsolved

@sandorfr

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.

@joeaudette

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

@MaximRouiller

I've stopped reading a while ago but I'll close this issue as soon as we have a definitive answer about project.json.

@gulshan
gulshan commented May 24, 2016

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.
@markrendle

yeahno

Yeah... no.

@MaximRouiller

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.

@smoothdeveloper

@MaximRouiller hope you'll gather the comments that focus on answering your initial questions despite the amount of noise.

@shederman

@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.

image

So sad.

@jerometerry

@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.

@sandorfr
sandorfr commented May 24, 2016 edited

Everything is awesome

@MacBaird

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.

@shederman

@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.

@Mike-EEE

BTW... was there even a standup yesterday? I signed into live.asp.net but the countdown just reset, with no video/feed or anything...

@jnm2
jnm2 commented May 25, 2016

@Mike-EEE They heard you were coming 😜

@morrisonbrett

Frustrating that they did this. I blogged about it: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

@jnm2
jnm2 commented Jun 2, 2016 edited
@morrisonbrett

He specifically addresses project.json here: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

@yetanotherchris
yetanotherchris commented Jun 5, 2016 edited

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.

@joeaudette

@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

@neoKushan
neoKushan commented Jun 5, 2016 edited

@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.

@yetanotherchris

@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.

@neoKushan
neoKushan commented Jun 5, 2016 edited

@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.

@joeaudette

@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

@joeaudette

@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

@jnm2
jnm2 commented Jun 7, 2016

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

@Mike-EEE
Mike-EEE commented Jun 8, 2016

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.

@jnm2
jnm2 commented Jun 8, 2016

As the program manager for .NET and Visual Studio, I doubt @coolcsh honestly has the spare time.

@shederman

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.

@Mike-EEE
Mike-EEE commented Jun 8, 2016

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. 😛

@erictor
erictor commented Jun 10, 2016 edited

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.

@shederman
shederman commented Jun 12, 2016 edited

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?

@neoKushan

@shederman are you an enterprise mobile dev, or enterprise UWP dev? Or Enterprise Unity Dev?

@shederman

None of the above. We write core systems for asset management and bank integration. Some Online stuff too.

@neoKushan

@shederman I suspect that might be why you weren't asked?

@shederman

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?

@neoKushan

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.

@shederman

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.

@neoKushan
neoKushan commented Jun 13, 2016 edited

maybe they should talk to all the developers.

Isn't that what they've been doing for the last 2+ years?

@poke
poke commented Jun 13, 2016

@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.

@shederman

@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.

@neoKushan

@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.

@chaoaretasty

@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".

@odytrice
odytrice commented Jun 16, 2016 edited

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

@PatriotBob
PatriotBob commented Jun 21, 2016 edited

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.

@MacBaird

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 notifications@github.com 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
#1433 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

@ysiivan
ysiivan commented Jul 7, 2016

The whole XML is bad, JSON is great hoopla was heavily over hyped. I like what PatriotBobo is saying.

@cdaringe

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 :$ :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment