I feel like there is a massive proliferation of overlapping APIs, runtimes, and environments for Windows. I remember back in the days of 16-bit Windows, there was “Win32s”, which was a partial port of “the” Win32 API…except that there were like eight mutually incompatible versions of Win32s…
(This proliferation extends to the UI too. For example, there’s “Settings” and “Control Panel” in Windows 10, with some settings in one, some in the other, some in both, and some in neither….)
I don’t really like .NET Core because of the utter mess it’s made out of compatibility and the CADT rewriting of tooling for .NET, but this is good news for anyone maintaining legacy desktop stuff.
Dotnet tooling was in such a poor 90s enterprise app state that it desperately needed a facelift. At least the really WTF parts (yeoman, dnf) were quickly refined into more sensible (project.json) solutions, and it is generally getting better (but the csproj format sometimes suggests that they are still holding XML wrong)
I want the remote (and local cli based) debugging to get better, as it is a bad joke currently.
My scenarios:
VS -> ssh -> remote linux -> docker -> dotnet app
VS -> ??? -> docker for windows -> dotnet app
With VS Code something is possible, but with VS I could not find any useful and working setup/docs. The docs are Hello World setups and for an existing complex real world usecase neither worked. There is no clean and technical description about the working of the tools, supported protocols, what is possible with what, ‘cause it’s open source now, so just find it out yourself! (At least now it is partially possible)
No, I was just trying to sum up the history of the tooling, and emphasize that it was always an improvement at each step. The msbuild they “went back to” is a step forward rather, in my opinion.
At least they dared to try new things, and I see it as it has revitalized the community.
I’m not sure about this - I see this a problem for the ecosystem by needless compatibility breaks and constantly shifting best practices that you’re never sure what’s current or not.
If revitalization means shifting it to something like the Node community in behaviour and attitudes, then I’m not sure if I want to participate in that.
I can sincerely feel your frustration about this, as I’ve also had some terrible weeks upgrading .Net Core versions on larger applications, but I believe these steps are better if done sooner than later, and the Desktop Framework has much luggage from the Enterprise Application Toolkit hell of the 1990s left over, which better gets left behind.
I think (rather hope) that the situation will stabilize now, as the node/npm hipster stuff was already tried, and mostly abandoned, and the existing stuff got facelifted (MSBuild), and this will be the trend overall the framework.
What I really don’t like is the mess C# is becoming (I despise async keyword and the inconsistencies it has brought), with the half-assed solutions, and the failed promise of Roslyn (which was anybody will be able to write language extensions, yet we can only write code parsers and generators. I cry out for Lombok)
I also find the tooling lacking compared to Java. I especially miss simple and reliable, working remote debugging (without having to install extra stuff on target), a JMX equivalent.
I feel like there is a massive proliferation of overlapping APIs, runtimes, and environments for Windows. I remember back in the days of 16-bit Windows, there was “Win32s”, which was a partial port of “the” Win32 API…except that there were like eight mutually incompatible versions of Win32s…
(This proliferation extends to the UI too. For example, there’s “Settings” and “Control Panel” in Windows 10, with some settings in one, some in the other, some in both, and some in neither….)
I don’t really like .NET Core because of the utter mess it’s made out of compatibility and the CADT rewriting of tooling for .NET, but this is good news for anyone maintaining legacy desktop stuff.
Dotnet tooling was in such a poor 90s enterprise app state that it desperately needed a facelift. At least the really WTF parts (yeoman, dnf) were quickly refined into more sensible (project.json) solutions, and it is generally getting better (but the csproj format sometimes suggests that they are still holding XML wrong)
I want the remote (and local cli based) debugging to get better, as it is a bad joke currently.
My scenarios: VS -> ssh -> remote linux -> docker -> dotnet app VS -> ??? -> docker for windows -> dotnet app
With VS Code something is possible, but with VS I could not find any useful and working setup/docs. The docs are Hello World setups and for an existing complex real world usecase neither worked. There is no clean and technical description about the working of the tools, supported protocols, what is possible with what, ‘cause it’s open source now, so just find it out yourself! (At least now it is partially possible)
I thought they removed that and went back to MSBuild…. are they back at it again?
No, I was just trying to sum up the history of the tooling, and emphasize that it was always an improvement at each step. The msbuild they “went back to” is a step forward rather, in my opinion.
At least they dared to try new things, and I see it as it has revitalized the community.
I’m not sure about this - I see this a problem for the ecosystem by needless compatibility breaks and constantly shifting best practices that you’re never sure what’s current or not.
If revitalization means shifting it to something like the Node community in behaviour and attitudes, then I’m not sure if I want to participate in that.
I can sincerely feel your frustration about this, as I’ve also had some terrible weeks upgrading .Net Core versions on larger applications, but I believe these steps are better if done sooner than later, and the Desktop Framework has much luggage from the Enterprise Application Toolkit hell of the 1990s left over, which better gets left behind.
I think (rather hope) that the situation will stabilize now, as the node/npm hipster stuff was already tried, and mostly abandoned, and the existing stuff got facelifted (MSBuild), and this will be the trend overall the framework.
What I really don’t like is the mess C# is becoming (I despise async keyword and the inconsistencies it has brought), with the half-assed solutions, and the failed promise of Roslyn (which was anybody will be able to write language extensions, yet we can only write code parsers and generators. I cry out for Lombok)
I also find the tooling lacking compared to Java. I especially miss simple and reliable, working remote debugging (without having to install extra stuff on target), a JMX equivalent.