Hacker News Reader

Comment by atonse | Hacker News Reader

I gotta agree that the excitement is waning – I don't know why they're moving away from the JSON file back to csproj files. These files are more or less opaque. Sure you can read them, but does anybody actually ever hand-edit them?

View on HN

It's an obvious move to make migration easier for devs. I certainly don't want JSON project files, I just want to be able to take my existing .NET projects as is and build them on Core. The only place I ever want to see JSON is as a response to some client side JavaScript call, that is its only valid use imho, everywhere else it's not as good as the alternatives.

Same with me. I like XML, the automated tooling it allows for and never got the point of the XML hate.

It was made for tools, not to be written by hand.

Agree, XML is fantastic and a much better choice than JSON for everything except being parsed by JavaScript. JSON has one use in this world, JavaScript.

Yea well, that's like, your opinion, man.

Yes, it is.

"tools" don't always exist or may not be available. So, as with all software, it must be possible to edit the files as text with a good developer experience.

Yes, but that should be the exception, not the rule.

I think that the hate usually comes from the PDP-11 programming crowd, whose only tools are the CLI and an editor.

>Yes, but that should be the exception, not the rule

Yeah, like it has been with .NET development on platforms where Visual Studio doesn't exist (read: all of them except Windows).

"should be" is a very different creature from "is", and is also very different from "will be".

> the hate usually comes from the PDP-11 programming crowd, whose only tools are the CLI and an editor.

Also known as "the every other platform except Windows" crowd, which apparently is substantial enough that even the one outlier -- Microsoft -- finally is trying to move in line with the rest of the world by allowing Bash and Linux tools in Windows 10.

You can be dismissive all you want, but that doesn't change the reality that CLI+editors are modern development (see also: almost every new language's ecosystem pivoting on CLI tooling and editor plugins), not the past.

> Also known as "the every other platform except Windows" crowd

I am yet to see iDevices and Android developers being PDP-11 devs or guys doing development on our Fortune 500 customers, regardless of the customer OS.

Strange, it sure looks like that at Amazon, at Netflix, at McKesson, at Facebook, at....you get the idea

But enough empty hot-air "name-dropping"; just cool your bluster, dude. You don't have to get all "look at me I'm better than you, I have all the best words, great words like 'Fortune 500'" just because you don't like CLIs.

You might be surprised to hear, then, that the vast majority of programmers are in the PDP-11 crowd

It doesn't look like that on the Fortune 500 offices I tend to sit on.

> It was made for tools, not to be written by hand.

...but people too often end up needing to read or write it by hand. That's the problem with XML. (Well, the other problem is that there is lots of data for which you'd want tooling for which a text-based markup format isn't ideal in the first place.)

I don't recall ever having a problem with hand editing XML, how is that the problem with XML?

Or the fact that in a lot of XML 90%+ of it is markup?

XML is one thing, MSBuild is another one. It's the only widely used tool where you can't really hand-craft (and therefore fully understand) a complete build file.

Compare Maven's pom.xml with a MSBuild file. Both XML, both verbose, but other than that, radically different.

There was a (very) brief period where I used a few hand-crafted MSBuild files. I don't remember it being all that bad (other than heavy learning curve) and there were even some things you could do simpler and nicer in a hand-crafted MSBuild file than what you see in Visual Studio's usage of MSBuild and the build files it generates.

I think a lot of people's issues with MSBuild are more to do with how Visual Studio uses MSBuild than with MSBuild itself. MSBuild has just about always supported wildcards and deeper incremental and partial build support, but Visual Studio hasn't. A lot of the hoops in hand-crafting an MSBuild file are there mostly if you want to make sure that Visual Studio can open the file...

Sure, but you have to look at the target audience, existing .Net developers; these devs in large already use MSBuild. They don't want Maven, they want their existing projects and solutions to simply open, build, and work as is. It's hard enough changing OS's, the last thing they want is for all the tools to change as well.

Microsoft is doing this because the .Net developers numbers are most likely dwindling (or at least stagnant, which is just as bad since it means there's not enough young blood coming in).

As a result the new solution must also cater to the new recruits they're trying to draw. I doubt many of those would like MSBuild, since it's not even liked by existing .NET devs :)

> I certainly don't want JSON project files,

I personally don't care much if it's XML or json, I just want it to be simpler and easier to use. And the RC1 demos of adding nuget packages by typing 1 readable line into project.json certainly where that.

If they make the csproj format package aware and treat files as included by default, I don't actually see any disadvantages over project.json. In fact, I think that a format that doesn't even have comments is terrible for this kind of stuff.

Yeah I do. Sometimes it's easier to just change a project reference in a solution file and reload, rather than do it through VS.

Or when a merge has gone wrong[1] and the project won't even open in VS any more.

[1] The default tortoise-svn merge tool (it's name I can't remember having switched to kdiff) is particularly horrid sometimes.

> Sure you can read them, but does anybody actually ever hand-edit them?

Let me assure you, that yes people do. Sometimes that's the only option to getting the build working like you want/need to.

Csproj-files are more or less Turing complete, so you can do lots and lots of things that the standard GUI tools will never permit you to.

Hell, I don't care if its XML/JSON/XAML but I don't want to go back to MSBuild/CSPROJ.

> Sure you can read them, but does anybody actually ever hand-edit them?

Sometimes yes, a targeted intervention into the .csproj file is the best/only way.

Yes I did. I needed to hook a custom build step in the build process of a Windows Phone application. But interfacing with MSBuild is not only editing the XML file, it is also about creating tasks in .net that can be called by MSBuild. In the end it was not that hard but still required some days of reading docs and trial.

Yeah, I do ocassionally.

Reply on news.ycombinator.com