4 ms·

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 supporte

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.

ad404b8a372f2b9 3y ago
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.
- CrendKing 3y ago
  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.
  - ntdll 3y ago
    Not true in my experience. The "look and feel" of the program usually gives it away more or less immediately.
    - grujicd 3y ago
      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.
      - ntdll 3y ago
        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 https://keepass.info/screenshots/main_big.png [1]: https://keepass.info/screenshots/keepass_2x/main_big.png https://keepass.info/screenshots/keepass_2x/main_big.png
        userbinator 3y ago
        The blurrier font in the non-native one is another difference.
    - EMM_386 3y ago
      > 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/irihitech/Semi.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia etc.
TillE 3y ago
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.
- formerly_proven 3y ago
  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)
- Uvix 3y ago
  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.
- pjmlp 3y ago
  Because the modern way is to ship it with the application and preferably use trimming.
- electroly 3y ago
  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.

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.

ad404b8a372f2b9 3y ago

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.

CrendKing 3y ago
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.
- ntdll 3y ago
  Not true in my experience. The "look and feel" of the program usually gives it away more or less immediately.
  - grujicd 3y ago
    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.
    - ntdll 3y ago
      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 https://keepass.info/screenshots/main_big.png [1]: https://keepass.info/screenshots/keepass_2x/main_big.png https://keepass.info/screenshots/keepass_2x/main_big.png
      - userbinator 3y ago
        The blurrier font in the non-native one is another difference.
  - EMM_386 3y ago
    > 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/irihitech/Semi.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia https://github.com/AvaloniaUI/Citrus.Avalonia etc.

TillE 3y ago

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.

formerly_proven 3y ago
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)
Uvix 3y ago
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.
pjmlp 3y ago
Because the modern way is to ship it with the application and preferably use trimming.
electroly 3y ago
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.