[Discussion] Project dependency after project.json phase out

[MaximRouiller]

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]

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

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]

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]

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]

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]

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.