141–150 of 231 posts
Only thing I want to hear about lately is the next major version of Visual Studio, I feel like it will never come. I always feel like every major version has drastic improvements, and I'm starved for them.
Still no migration path from WinForms to something modern.
I love .NET but if you're taking on an older desktop app that is still using VB.NET and WinForms it feels like Microsoft have decided to let you circle the drain with no supported way forward into MAUI or whatever stupid XAML UI they decided is the solution these days.
On a server, .NET is fantastic and it's entirely possible to build and debug your system on Linux with no loss of productivity, but the desktop stuff is bad and getting worse.
Only thing I want to hear about lately is the next major version of Visual Studio, I feel like it will never come. I always feel like every major version has drastic improvements, and I'm starved for them.
> "Stay tuned for more details later this summer about what's coming next for Visual Studio..."
https://learn.microsoft.com/en-us/visualstudio/releases/2022...
Only thing I want to hear about lately is the next major version of Visual Studio, I feel like it will never come. I always feel like every major version has drastic improvements, and I'm starved for them.
Have you tried Rider?
My favorite .NET 10 feature so far is not within the .NET library itself, but `dotnet tool exec` to run C# files as scripts without a build step. This has been available in F# for a long time via `dotnet fsi`, and for C# also via the third party cs-script tool. It took a surprisingly long time to officially reach the primary .NET language! I only really wish C# would’ve been directly integrated as an alternative scri…
You can embed C# in PowerShell scripts, and you have been able to do so for a long time. This webpage has a couple of examples of how this can work:
Earlier quoted context omitted.
> .NET nowadays has a serious adoption problem It's seriously going to make people question the future of the platform. Look at Microsoft's actions, not their words. TS Compiler: Go New TUI Editor: Rust Winget: C++ (this would have been a great candidate for .NET) At least PowerToys is C#. .NET is great, but why isn't it good enough for Microsoft? The company that historically has had such a strong culture of dogfood…
The issue was in the beginning they didn’t think interop with C/C++ was value add. People complained and they added “Managed C++” which unfortunately influenced C++03’s design a lot. It wasn’t until C++11 that Microsoft gave up. You couldn’t effectively interop with C++ without writing a managed C++ wrapper, which only worked on windows. They added support for P/Invoke to aid in Win32 calls (shell.dll, user32.dll) as…
P/Invoke was born as J/Direct on J++, it became P/Invoke after the lawsuit, and Cool project turned into C#.
Managed C++ Extensions in .NET 1.0 got replaced by C++/CLI on .NET 2.0, it was a .NET Core 3.1 milestone to support it, and has recently been updated up to C++20, minus modules.
Still heavily used among .NET community on Windows.
Meanwhile the native C++/CX and C++/WinRT, both failed their adoption efforts.
Earlier quoted context omitted.
I've wanted this for a long time. After reading this link, and the MS release announcement, I still don't understand what a "tool" is, or how you can use `tool exec` to run a single *.cs file. Is there a straight-forward recipe anywhere for doing this targeted at absolute simpletons?
Well if you're familiar with the node ecosystem it's a corollary for npx/bunx/etc. It is so that folks can build and run "tools" that are executed, utilizing the nuget ecosystem. Relevant links in the dotnet docs (was just a quick google away): * https://learn.microsoft.com/en-us/dotnet/core/tools/global-t... * https://learn.microsoft.com/en-us/dotnet/core/tools/global-t... It's actually a top-level doc section in th…
Earlier quoted context omitted.
I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what…
>I still haven't found a use-case for the websocket Blazor Hybrid and it still smells so much like the worst mistakes of the original ASP (before .NET) and the `runat="client"` versus `runat="server"` confusions. That is exactly my read of it, especially given Microsoft track record on delivering with stuff like this. Not sure about the Silverlight comparison - in the days of Flash, browsers did not even have a way t…
Sometimes the "event loop" part is forgotten because JS' single threaded thing is very "cooperatively threaded". This is a large part of why async/await works so well in JS and is growing so quickly in adoptions. .NET's multithreading is built in a way to excel in "cooperatively threaded" environments (its task pools are cooperative by default, for instance, and also arguably heavy use of async/await was C#'s idea first).
It would be great to see more WASM multithreading powers, but writing C# for today's WASM environment doesn't feel that different from "regular" multi-threaded C#.
> I know for a fact that the iteration/build/debugging story sucks compared to native JS/TS
WASM debugging is nearly great, including growing Sourcemap support. The ability for Visual Studio to be the Debugger interface to Chromium-based browsers is more powerful that ever. Certainly in its debugging story Blazor WASM is much advanced from Silverlight which was only really debuggable in IE and then was still often flaky.
> DOM APIs are built for JS
There's still talk of making more direct DOM APIs for WASM. Might be interesting to see eventually.
This is why it is so easy to relate Blazor WASM to React. Blazor is essentially using Razor templates to define a Virtual DOM which it then sends render updates across the WASM/JS boundary to a very tiny virtual DOM renderer.
It's not what I'd use for smarter direct DOM work, but in comparison to React it gets the job done and works surprisingly well, even with the language barrier and data marshalling across sandbox layers.
I've used Blazor WASM on Enterprise projects. I'd probably use it again on Enterprise projects. It can be real nice to have backend and frontend all entirely in C#. (In different projects. So that you can scale them independently if nothing else.)
Earlier quoted context omitted.
I very much doubt about TS.Net, given the rewrite in Go decision. .NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.
Not sure I agree on the adoption problem. A few medium sized client projects are nothing compared to the massive internal .NET codebases Microsoft has that run some of their largest services.
Earlier quoted context omitted.
Many things under Satya also feel like good old Microsoft, like lack of GUI frameworks for GNU/Linux, killing VS4Mac after the rewrite, dotnet watch drama, profiling tools being VS only,...
VS4Mac deserved to die, that was Mono Code aka Xamarin and it was terrible. No offense to Miguel, mono is amazing, but the IDE they made was horrid. Microsoft was asleep at the wheel the last decade of Ballmer, leaning too heavily on their Xbox Studios and Enterprise Cloud to care about desktops. They gladly let Mac take office share as “no enterprise software developer would ever choose a Mac”. Those famous Mac vs P…
I rather use XAML, if given the choice.