[Discussion] Project dependency after project.json phase out

[MaximRouiller]

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

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

• Most of the non-NuGet stuff will get merged to csproj. What will happen to NuGet stuff if there's no project.json (nuget.json?) ?
• Will we be keeping the IntelliSense for dependency management? This is basically one of the best demo features we have for project.json.
• Are we keeping the JSON format for dependency management? XML is horrible for those kinds of things (see Maven). JSON is hands down simpler to represent those dependencies.

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

Thank you,

[darrelmiller]

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

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

[shawnwildermuth]

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

[sandorfr]

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

[darrelmiller]

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

[sandorfr]

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

[tugberkugurlu]

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

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

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

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

[shederman]

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

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

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

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

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

[cwe1ss]

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

In my opinion that would be:

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

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

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

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

[imranbaloch]

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

[cwe1ss]

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

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

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

[sandorfr]

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

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

[julielerman]

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

[shederman]

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

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

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

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

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

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

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

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

[cwe1ss]

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

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

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

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

[JulianRooze]

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

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

[shederman]

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

[shawnwildermuth]

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

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

[ejsmith]

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

[MaximRouiller]

My favorite quote on MSBUILD files?

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

Source

[darrelmiller]

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

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

[MaximRouiller]

@darrelmiller I agree.

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

[dustinmoris]

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

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

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

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

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

[shederman]

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

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

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

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

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

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

[dustinmoris]

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

[shederman]

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

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

[shederman]

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

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

[dustinmoris]

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

[smbecker]

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

[shederman]

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

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

Why do MS not give a damn what people think?

[Mike-E-angelo]

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]

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

[shederman]

I'd be quite horrified if he's unaware of the feedback that's been given. Maybe not all the details, but certainly that there's been significant pushback.

[Mike-E-angelo]

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]

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]

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

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

[neoKushan]

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

[shederman]

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

[neoKushan]

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

[shederman]

Please clarify?

Are you really saying that the only corporate devs MS now supports are those doing mobile work for 1% of the market, UWP apps for um, the 5% of users who care, and game development? Out of the entire spectrum of development, MS is turning their back on everything but that?

[neoKushan]

Umm. No.

I'm saying that the changes came about after talking to those groups, so that's why you weren't asked. Microsoft has to support all of their developers, not just the asp developers.

[shederman]

Yes, so if they're going to support all their developers, maybe they should talk to all the developers. Maybe just talking to a selected subset 5% of enterprise developers is not a good way of gauging the opinions of enterprise developers as a whole.

So, to get a large bank's opinion listened to, we must switch all our development to UWP/Unity/Mobile?

That's ridiculous.

[neoKushan]

maybe they should talk to all the developers.

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

[poke]

@shederman So just because you personallly weren’t asked, you are implying that nobody else who covers your development range was involved?

Also, stop making up those numbers – that’s ridiculous.

[shederman]

@poke I'm asking who WAS involved? I'm saying that I've heard enterprise dark matter developers were consulted, and pointed out that I'm at bank, and we weren't, so who exactly was?

I actually thought the numbers were quite generous, but okay.

[neoKushan]

@shederman I think you're looking too much into this whole thing. The focus for the last 2 years has been squarely on the asp.net side of things, but as word of .net core started to spread, a lot of people started asking "How can I use this?". It wasn't some back room deal, it was people asking for literally years. You only have to look around to see many people wanted more from .net core.

There is also the matter of actual enterprise support requests from big organisations wanting to know how to port their existing stuff over to be cross-plat - you probably weren't "Asked" because you didn't require someone from Microsoft telling you that what you are trying to do is beyond the scope of the project.

Another way to look at it - and the way I personally view it - is you have been asked, you were asked the second the announcement was made months ago. For all the cries of people saying decisions were made without consulting anyone, Microsoft has repeatedly stated that they're still working out details, that they still don't have the final pieces put together and now is the time to voice your opinion. Scott Hunter even said that if people really want project.json as an option, they'll consider keeping it. Go watch the dotnetconf keynote if you don't believe me.

[chaoaretasty]

@neoKushan I appreciate that Scott stepped back a bit saying that they would consider keeping it, but there really needs to be a single, centralised point for people to express that this is what they want otherwise the project.json issue will keep popping up in discussions everywhere. It also means then that when it is brought up everyone can reply with the same "hey, they'll consider keeping it if developers really want it, here is where you go to let them know".

[odytrice]

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]

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]

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]

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

[cdaringe]

managing a s/w project entirely from npm's package.json has never so simply and concisely made declaring my project, building my project, upgrading my project (e.g. greenkeeper), read/writing/parsing data about my project, and publishing my project so easy. so easy. as many of us, my history is in c++/java/python/node, with play in others. i long for the npm experience in all of my projects now.

the project.json promised to yield these same characteristics. i think it's a model worth emulating, and not sacrificing the simplicity and power.

if the team .net core team thinks the other solution can provide these traits, excellent, and power to 'em! however, please don't undermine the beauty in the simplicity as you progress.

also, i understand that i'm just noise by this point in a giant thread. maybe the moderators ought consider closing it and handling the ordeal in more controlled fashion. lots of good feedback. maybe a little trolling too :$ :)