New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
@MaximRouiller

MaximRouiller commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@darrelmiller

darrelmiller May 11, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@shawnwildermuth

shawnwildermuth May 11, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@sandorfr

sandorfr May 11, 2016

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

sandorfr commented May 11, 2016

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

@darrelmiller

This comment has been minimized.

Show comment
Hide comment
@darrelmiller

darrelmiller May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@sandorfr

sandorfr May 11, 2016

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.

sandorfr commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tugberkugurlu

tugberkugurlu May 11, 2016

Member

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.

Member

tugberkugurlu commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 11, 2016

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

+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

This comment has been minimized.

Show comment
Hide comment
@cwe1ss

cwe1ss May 11, 2016

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.

cwe1ss commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@imranbaloch

imranbaloch May 11, 2016

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

IMHO, the main problem is that these types of drastic changes just before RTM is not good. 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

This comment has been minimized.

Show comment
Hide comment
@cwe1ss

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

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

This comment has been minimized.

Show comment
Hide comment
@sandorfr

sandorfr May 11, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@julielerman

julielerman May 11, 2016

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

i'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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 11, 2016

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

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

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

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

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

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

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

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

I think 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

This comment has been minimized.

Show comment
Hide comment
@cwe1ss

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

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

This comment has been minimized.

Show comment
Hide comment
@JulianRooze

JulianRooze May 11, 2016

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.

JulianRooze commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment

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

@shawnwildermuth

This comment has been minimized.

Show comment
Hide comment
@shawnwildermuth

shawnwildermuth May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@ejsmith

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

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

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller May 12, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@darrelmiller

darrelmiller May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller May 12, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris May 12, 2016

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.

dustinmoris commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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%

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

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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!

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

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@smbecker

smbecker May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@dustinmoris

dustinmoris May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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 commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@rhires

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

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@abcplex

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

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

This comment has been minimized.

Show comment
Hide comment
@darrelmiller

darrelmiller May 12, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@abcplex

abcplex 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

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

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@MaximRouiller

MaximRouiller May 12, 2016

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.

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.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 25, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 May 25, 2016

@Mike-EEE They heard you were coming 😜

jnm2 commented May 25, 2016

@Mike-EEE They heard you were coming 😜

@morrisonbrett

This comment has been minimized.

Show comment
Hide comment

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

@jnm2

This comment has been minimized.

Show comment
Hide comment

jnm2 commented Jun 2, 2016

@morrisonbrett

This comment has been minimized.

Show comment
Hide comment
@morrisonbrett

morrisonbrett Jun 2, 2016

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

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

@yetanotherchris

This comment has been minimized.

Show comment
Hide comment
@yetanotherchris

yetanotherchris Jun 5, 2016

Although the project.json format is far simpler to edit (unless you're at that stage of .NET dev of being a drag and drop dataset-monkey), the biggest problem for me is nobody is bothering to update their libraries to the .netcore. So far I've managed to get one branch of Restsharp working, but this uses the project.json format. JSON.NET, Structuremap, NUnit etc. etc. all have stale DNX branches where it looks like the developers abandoned hope.

So it's a bit strange to call the .NET Core RC1/2 a release candidate when the project format the dotnet command line tool is being removed. That to me is still beta or even alpha software as it's experimental.

My main motivation for moving to vNext is to make use of cheap Linux hosting, and Docker. A project migration tool ASAP would be wise as most people will be completely handicapped by their libraries via nuget references missing .NET Core versions.

yetanotherchris commented Jun 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@joeaudette

joeaudette Jun 5, 2016

@yetanotherchris dnx was a concept in rc1, it changed to dotnet cli in rc2, so most dnx projects or branches would be stale at this time

project.json is still here and needed for rc2, discussion about it going away in the future after RTM

json.net aka newtonsoft.json does work and is used by the framework itself, I use it in my projects too
nunit is not compatible, everyone uses xunit afaik
structuremap does have and rc2 compatible library

there are still lots of 3rd party things not yet ported to rc2, but Microsoft does not control the timing of other projects and when they will make compatible libraries

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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 5, 2016

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

neoKushan commented Jun 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@yetanotherchris

yetanotherchris Jun 5, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 5, 2016

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

neoKushan commented Jun 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@joeaudette

joeaudette Jun 5, 2016

@yetanotherchris you have to remember that rc2 is preview and so you have to look for preview packages from 3rd parties also
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

I don't know about NUnit if it will be supported later but for now on .NET Core and ASP.NET Core projects people are using xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

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

This comment has been minimized.

Show comment
Hide comment
@joeaudette

joeaudette Jun 5, 2016

@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

@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

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 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

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

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

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

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Jun 8, 2016

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

jnm2 commented Jun 8, 2016

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

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 8, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

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

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

This comment has been minimized.

Show comment
Hide comment
@erictor

erictor Jun 10, 2016

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.

erictor commented Jun 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 12, 2016

As I've said many times, I'm an enterprise developer at a major bank, an enterprise customer. WE weren't consulted about these changes. So WHO exactly were the "dark matter enterprise developers"? That information is apparently top, top secret. 007 level stuff.

It's all well and good asserting that enterprise customers carry a big stick, but apparently it's only SOME of them that get to do so. Which ones? Based on what criteria? How do we get into that privileged list? What partner level is it? What annual spend? Inquiring minds want to know how much EXACTLY we need to be paying MS before they actually listen to our opinions?

shederman commented Jun 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 12, 2016

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

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

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 12, 2016

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

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

@neoKushan

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 12, 2016

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

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

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 13, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 13, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 13, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 13, 2016

maybe they should talk to all the developers.

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

neoKushan commented Jun 13, 2016

maybe they should talk to all the developers.

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

@poke

This comment has been minimized.

Show comment
Hide comment
@poke

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

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

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman Jun 13, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@neoKushan

neoKushan Jun 13, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@chaoaretasty

chaoaretasty Jun 16, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@odytrice

odytrice Jun 16, 2016

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

odytrice commented Jun 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@PatriotBob

PatriotBob Jun 21, 2016

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.

PatriotBob commented Jun 21, 2016

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.

@mac-bhaird

This comment has been minimized.

Show comment
Hide comment
@mac-bhaird

mac-bhaird Jun 21, 2016

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
.

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

This comment has been minimized.

Show comment
Hide comment
@ysiivan

ysiivan Jul 7, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@cdaringe

cdaringe Jul 14, 2016

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

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