Hacker News Reader

Comment by Kwpolska | Hacker News Reader

The .NET Framework is built into Windows, and a mandatory component of it since at least Vista. .NET Framework 4.7.2 specifically should be built-in on supported Windows versions.

View on HN

You never have the right version installed though. Every time I've tried to install a .NET program it's always asked me to install a different version than the one I had.

Sounds like confirmation bias, because when the right version of .NET is ever used, you probably never knew it was a .NET program to begin with.

Not true in my experience. The "look and feel" of the program usually gives it away more or less immediately.

Probably, if that app uses WPF, which is "self-drawn" GUI library. However, if .Net app uses WinForms, that API is just a wrapper over standard Win32 controls and it looks like any other old school Win app.

You're right, but there are a few subtle differences here and there that often make Windows Forms recognizable.

The best example I got off the top of my head is KeePass v1 [0] and KeePass v2 [1]. v1 is written in C++ with native controls, and v2 uses Windows Forms.

If you look at the menu bar and the toolbar, you'll see a difference. Most notably the drag handle on the left, and the search box on the right, in v2. The difference is often a bit easier to spot on Windows 7.

[0]: https://keepass.info/screenshots/main_big.png [1]: https://keepass.info/screenshots/keepass_2x/main_big.png

The blurrier font in the non-native one is another difference.

> The "look and feel" of the program usually gives it away more or less immediately.

If you are talking about the base controls, then maybe. But there are .Net cross-platform frameworks such as Avalonia that can get you a modern loooking UI with theming.

https://github.com/irihitech/Semi.Avalonia

https://github.com/AvaloniaUI/Citrus.Avalonia

etc.

I'm surprised Microsoft still isn't pushing .NET 6 (and the MSVC runtime, for that matter) to everyone with Windows Update. They're not very large, most consumers will want them, and picky enterprises could opt out.

It's an odd annoyance that Windows developers have to deal with.

Congruent with runtimes (both .NET and native) for Microsoft languages always being kinda weird. "Uh yeah don't use that CRT in %WINDIR%, that's not supported! Everyone need to bring their own... but not as loose DLLs, that's not allowed! Use the MSI package and install it whenever!" (I think most of those restrictions have been removed in the last couple years, and MS also settled down on VC++ ABI and VCRT changes and introduced UCRT in Windows 10, so)

They push updates to .NET if it’s installed. I can understand them not installing if it’s absent, because there’s no good story for what to do when that version goes out of support. If they leave it, then customers have insecure unsupported software on their systems; if they remove it, they’ll break apps that depend on it.

Because the modern way is to ship it with the application and preferably use trimming.

Getting your thing adopted as a Windows component and distributed by Windows Update is a common trap for Microsoft developers. It's always a mistake if you're in some DevDiv or random app team instead of the Windows team. Windows is the slowest-moving product that Microsoft has, and users don't install updates. Hitching your wagon to Windows means no two users will have the same version installed, and getting people to update .NET via Windows Update is a nightmare. God forbid the Windows team decides to stop supporting a version of Windows that is still commonly use in industry; they'll never get a .NET update again.

As a user, think about how annoying it is to get a message saying you need to run Windows Update before you can start an application. Totally unnecessary own-goal for the team that decided to ship their independent component in Windows Update.

It's way easier to either 1.) go self-contained, or 2.) use the on-the-fly .NET download for a framework-dependent build. I absolutely think they made the right call removing current .NET as a Windows component. The annoyance was far greater when .NET Framework was part of Windows.

Reply on news.ycombinator.com