6 ms·

Somewhat off topic, but all the excitement and hoorah surrounding .NET Core is beginning to fade for me. It seems that the product is beginning to turn into .N

by dvcc 10y ago

Somewhat off topic, but all the excitement and hoorah surrounding .NET Core is beginning to fade for me. It seems that the product is beginning to turn into .NET 5 (Core) instead of the original intentions of leaving behind the legacy chains. Between the switch back to MSBuild, RC# breaking changes and the promise of even more breaking changes post-release, I've become a little disheartened. Change in itself isn't bad, but .NET Core was supposed to be about open communication, and the later changes were never discussed within the actual community, instead it was decided by MS alone. Hell, in this article, it took multiple attempts to get it configured when its in the release-candidate stage. No idea where this was going it was more of a rant than anything apologies for anyone who actually read it.

atonse 10y ago
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?
- gnaritas 10y ago
  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.
  - pjmlp 10y ago
    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.
    - gnaritas 10y ago
      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.
      - amarka 10y ago
        Yea well, that's like, your opinion, man.
        gnaritas 10y ago
        Yes, it is.
    - intrasight 10y ago
      "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.
      - pjmlp 10y ago
        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.
        ubertaco 10y ago
        >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.
  - oblio 10y ago
    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.
    - WorldMaker 10y ago
      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...
    - gnaritas 10y ago
      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.
      - oblio 10y ago
        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 :)
  - SideburnsOfDoom 10y ago
    > 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.
- Spearchucker 10y ago
  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.
  - eterm 10y ago
    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.
- thomasz 10y ago
  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.
- dvcc 10y ago
  Hell, I don't care if its XML/JSON/XAML but I don't want to go back to MSBuild/CSPROJ.
- recursive 10y ago
  Yeah, I do ocassionally.
- josteink 10y ago
  > 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.
- SideburnsOfDoom 10y ago
  > 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.
- titanix2 10y ago
  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.
treehau5 10y ago
Call me crazy, but I think long term this will be a good thing for Java. (I am one of those people who actually enjoys Java, I know call me crazy) My organization for example used to be all PHP and JavaScript. This whole "static language" thing is new to them. They tried C# and thought it was the greatest thing since sliced bread, (along with Go). So they heard about Microsoft going "open source" and decided to give it a spin. Now with the 'boiling the ocean' article ringing true for many, people are starting to get some heartburn about having to get in bed with Microsoft. I stand over in the corner and raise my hand occasionally and say, "How about Java?" every now and then.
- wvenable 10y ago
  Once you've used C#, it's really hard to go to Java. If they were radically different, it might be easier, but instead Java just presents itself as a worse version of C#. Microsoft can fix their platform issues but Java the language can't really be meaningfully improved. So, in my opinion, it's still Microsoft's game to win or lose.
  - bad_user 10y ago
    Microsoft has repeatedly demonstrated that they cannot fix their "platform issues", which also includes tooling. For example getting back to an environment that uses MSBuild and Visual Studio for builds, dependency management, continuous integration and whatnot, after having used Maven, SBT, Leiningen and their ilk, feels like going back to the nineties. Even worse, your IDE of choice needs plugins to have working refactoring and it still can't handle automatic downloading of source code for third party dependencies, but at the same time manages to be bloated, and you still consider it the best IDE ever. I also think .NET developers get too fixated on Java the language. We've got Netty, Apache Spark, Hadoop and Cassandra and we've got Clojure, Scala, JRuby and Groovy. In other words a big ecosystem powered by what proved to be a multi language runtime not just in marketing brochures.
    - wvenable 10y ago
      Honestly one of the big problems I have getting into Java-the-ecosystem is the huge number of frameworks, tools, languages, etc that all compete with each other. The solution to every Java problem is just more: more tools, more syntax, more languages. It's hard to get started in that situation. If you're already well into it all, then one more thing is just one more thing.
benaadams 10y ago
The changes have been announced well ahead of being designed or implemented; so at this stage are "proposed" changes. There are issues on github where they are working through various designs; people are giving feedback, they are listening to them, iterating, improving - they written blogs about why, again taking feedback responding etc So that's pretty early community on-boarding - its not like they have already designed and implemented it without consultation and did a surprise change - its still in an open design phase.
- dvcc 10y ago
  The changes were announced ahead of time, but within the discussion there hasn't really been actual consideration around not switching back to MSBuild. They've been pretty set on the it within the Github issues (#1433) and haven't provided too much reasoning for it outside of tooling. Of course it's not that alone either there is just a bunch of confusion around it right now on the direction of .NET Core. From one of the end comments: > If you want to work out how it should be made and be in the design team that talks about it... please do. [Link to MS Career Page]
  - benaadams 10y ago
    There were two blog posts around the why: Making it easier to port to .NET Core https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/ https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it... Changes to Project.json https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t... Scott Hunter, Damain Edwards and Jon Galloway recently did a live community standup video about them https://youtu.be/YJsQ3tnS7Ew?t=10m39s https://youtu.be/YJsQ3tnS7Ew?t=10m39s
    - dvcc 10y ago
      I get that they have gave their reasoning (all those links were already grayed out), but its much more an announcement than it is a discussion. In the end though, it feels more like an executive decision than a collective push.
TheRealDunkirk 10y ago
It seems perfectly in line with every other announcement from Microsoft over the past 20 years. Every time they start an exciting new project, they astroturf the snot out of the announcement, in the press and online, to make it seem like it's more production-ready than it is, and then it takes longer than anyone predicted, and the things that made the announcement interesting (like getting away from MSBuild) wind up getting scrapped. I don't know why this pattern surprises anyone any more. I'm still waiting for Bash on Windows to support RVM and bootstrapping a Rails environment, but, then, I'm still waiting for the filesystem improvements promised in Cairo.
- maxxxxx 10y ago
  It seems to me that at MS they have smart guys come up with a good idea. These people are deemed too valuable to actually do this so management hands off the work to some inexperienced people. My company often does the same with things like refactoring or source control strategy. Good people are needed for project work so some intern gets to do a massive refactoring with bad results.
  - Philipp__ 10y ago
    It's Microsoft, their things always start with fantastic idea/concept but the implementation and delivery never gets it nowhere near as hoped. Oh well...

by dvcc 10y ago

atonse 10y ago

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?

gnaritas 10y ago
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.
- pjmlp 10y ago
  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.
  - gnaritas 10y ago
    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.
    - amarka 10y ago
      Yea well, that's like, your opinion, man.
      - gnaritas 10y ago
        Yes, it is.
  - intrasight 10y ago
    "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.
    - pjmlp 10y ago
      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.
      - ubertaco 10y ago
        >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.
- oblio 10y ago
  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.
  - WorldMaker 10y ago
    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...
  - gnaritas 10y ago
    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.
    - oblio 10y ago
      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 :)
- SideburnsOfDoom 10y ago
  > 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.
Spearchucker 10y ago
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.
- eterm 10y ago
  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.
thomasz 10y ago
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.
dvcc 10y ago
Hell, I don't care if its XML/JSON/XAML but I don't want to go back to MSBuild/CSPROJ.
recursive 10y ago
Yeah, I do ocassionally.
josteink 10y ago
> 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.
SideburnsOfDoom 10y ago
> 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.
titanix2 10y ago
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.

treehau5 10y ago

Call me crazy, but I think long term this will be a good thing for Java. (I am one of those people who actually enjoys Java, I know call me crazy) My organization for example used to be all PHP and JavaScript. This whole "static language" thing is new to them. They tried C# and thought it was the greatest thing since sliced bread, (along with Go). So they heard about Microsoft going "open source" and decided to give it a spin. Now with the 'boiling the ocean' article ringing true for many, people are starting to get some heartburn about having to get in bed with Microsoft. I stand over in the corner and raise my hand occasionally and say, "How about Java?" every now and then.

wvenable 10y ago
Once you've used C#, it's really hard to go to Java. If they were radically different, it might be easier, but instead Java just presents itself as a worse version of C#. Microsoft can fix their platform issues but Java the language can't really be meaningfully improved. So, in my opinion, it's still Microsoft's game to win or lose.
- bad_user 10y ago
  Microsoft has repeatedly demonstrated that they cannot fix their "platform issues", which also includes tooling. For example getting back to an environment that uses MSBuild and Visual Studio for builds, dependency management, continuous integration and whatnot, after having used Maven, SBT, Leiningen and their ilk, feels like going back to the nineties. Even worse, your IDE of choice needs plugins to have working refactoring and it still can't handle automatic downloading of source code for third party dependencies, but at the same time manages to be bloated, and you still consider it the best IDE ever. I also think .NET developers get too fixated on Java the language. We've got Netty, Apache Spark, Hadoop and Cassandra and we've got Clojure, Scala, JRuby and Groovy. In other words a big ecosystem powered by what proved to be a multi language runtime not just in marketing brochures.
  - wvenable 10y ago
    Honestly one of the big problems I have getting into Java-the-ecosystem is the huge number of frameworks, tools, languages, etc that all compete with each other. The solution to every Java problem is just more: more tools, more syntax, more languages. It's hard to get started in that situation. If you're already well into it all, then one more thing is just one more thing.

benaadams 10y ago

The changes have been announced well ahead of being designed or implemented; so at this stage are "proposed" changes. There are issues on github where they are working through various designs; people are giving feedback, they are listening to them, iterating, improving - they written blogs about why, again taking feedback responding etc So that's pretty early community on-boarding - its not like they have already designed and implemented it without consultation and did a surprise change - its still in an open design phase.

dvcc 10y ago
The changes were announced ahead of time, but within the discussion there hasn't really been actual consideration around not switching back to MSBuild. They've been pretty set on the it within the Github issues (#1433) and haven't provided too much reasoning for it outside of tooling. Of course it's not that alone either there is just a bunch of confusion around it right now on the direction of .NET Core. From one of the end comments: > If you want to work out how it should be made and be in the design team that talks about it... please do. [Link to MS Career Page]
- benaadams 10y ago
  There were two blog posts around the why: Making it easier to port to .NET Core https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/ https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it... Changes to Project.json https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t... Scott Hunter, Damain Edwards and Jon Galloway recently did a live community standup video about them https://youtu.be/YJsQ3tnS7Ew?t=10m39s https://youtu.be/YJsQ3tnS7Ew?t=10m39s
  - dvcc 10y ago
    I get that they have gave their reasoning (all those links were already grayed out), but its much more an announcement than it is a discussion. In the end though, it feels more like an executive decision than a collective push.

TheRealDunkirk 10y ago

It seems perfectly in line with every other announcement from Microsoft over the past 20 years. Every time they start an exciting new project, they astroturf the snot out of the announcement, in the press and online, to make it seem like it's more production-ready than it is, and then it takes longer than anyone predicted, and the things that made the announcement interesting (like getting away from MSBuild) wind up getting scrapped. I don't know why this pattern surprises anyone any more. I'm still waiting for Bash on Windows to support RVM and bootstrapping a Rails environment, but, then, I'm still waiting for the filesystem improvements promised in Cairo.

maxxxxx 10y ago
It seems to me that at MS they have smart guys come up with a good idea. These people are deemed too valuable to actually do this so management hands off the work to some inexperienced people. My company often does the same with things like refactoring or source control strategy. Good people are needed for project work so some intern gets to do a massive refactoring with bad results.
- Philipp__ 10y ago
  It's Microsoft, their things always start with fantastic idea/concept but the implementation and delivery never gets it nowhere near as hoped. Oh well...