5

I was planning to upgrade WinForms applications from .NET Framework to .NET 6, but unfortunately trimming is disabled for Windows Forms and WPF applications in .NET 6. https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities. This rules out a stand-alone deployment since each install will now be well over 100MB (currently, my .NET Framework versions have a 2MB install). In .NET 5, with trimming still allowed for WinForms, this was less than 50MB, which may have been borderline acceptable, but I'd like to use .NET 6.

The framework-dependent build option unfortunately has the critical error message box "To run this application you must install .NET Desktop Runtime 6.0.0". The appearance of this message is sure to scare off a certain segment of potential customers (the critical error red x, etc.) from even bothering to install the trial/demo/free edition.

Is there another option? I'm using InnoSetup, so any option has to be compatible with this.

Update Oct 28 2022: I'm currently using a .NET 6 self-contained (but not single-file) install. I adjusted my custom build utility to remove the WPF assemblies which for some inexplicable reason are included by dotnet publish for WinForms builds. After removing the WPF assemblies, the compressed setup exe is large (38 MB), but acceptable. Someone needs to sharpen up this sloppy build output for WinForms (not sure if this would be Microsoft or some random person on github).

Update Nov 15 2022: The data transfer rates for users downloading the large self-contained builds were unacceptable, so back to .NET Framework again for now. Would like to do 'framework-dependent' builds, but the .NET Desktop Runtime does not install after answering 'yes' to the ugly prompt asking whether to download it. (The ugly prompt goes away after answering 'yes', but nothing else happens). How are others getting around this? I thought by now Microsoft would have had enough feedback to make this work.

Update Nov 16 2022: Now we're producing 'framework-dependent' builds, which are roughly the same size as the .NET Framework 4.8 builds. The ugly prompt to install .NET Desktop Runtime is not ideal and to get the prompt to actually work you have to use "PublishSingleFile=true" for some bizarre reason.

Update Jan 13 2023: Well, we upgraded to .NET 7 and after months of user complaints about install issues, we're back to building for .NET Framework 4.8. The reason for this is the bewildering choices Microsoft has made about .NET 7 framework-dependent applications. Users are now prompted separately for 2 different installs (Microsoft.NETCore.App and Microsoft.WindowsDesktop.App, in that order), even though the second includes the first! Users were confused and thinking they were being prompted for the same thing again, gave up on the install, thinking the install was broken. This can be reproduced by creating a .NET 7 WinForms application and then installing (I use Inno Setup) to a machine without .NET 7. You'll be prompted first for Microsoft.NETCore.App and after this install, attempting to run the application will result in yet another prompt for Microsoft.WindowsDesktop.App. So a .NET 7 desktop application will fail to run the first two times, prompting for .NET 7 installs, when just the second one would take care of it! I have to seriously wonder if Microsoft has enough people working on this.

Dave Doknjas
  • 6,394
  • 1
  • 15
  • 28
  • It is shown in extra bold type on the [download page](https://dotnet.microsoft.com/en-us/download/dotnet/7.0) for the .NET 7 desktop runtime install: **This release includes the .NET Runtime; you don't need to install it separately**. Hopefully some day InnoSetup gets smarter about it. But notable how such tooling does have a knack for creating a crutch instead of actually helping anybody. – Hans Passant Jan 13 '23 at 17:40
  • It's not an InnoSetup problem. The setup completes and then on first attempting to run the .NET 7 WinForms application, you are first prompted for "Microsoft.NETCore.App" and later for "Microsoft.WindowsDesktop.App", when it should just prompt for "Microsoft.WindowsDesktop.App". I'm ok with just one prompt, but having the application fail to start twice for two separate installs is ludicrous. It's an obvious oversight. – Dave Doknjas Jan 13 '23 at 18:21
  • @HansPassant: Just to clarify, I'm not configuring InnoSetup to install .NET 7 - I'm relying on the default behavior of running a .NET 7 WinForms application when .NET 7 isn't installed. The application fails immediately with a prompt and link to install the .NET 7 runtime - this I'm ok with. Failing twice is the problem. – Dave Doknjas Jan 13 '23 at 18:31
  • Mystifying why you wouldn't use InnoSetup to install .net7 – Hans Passant Jan 13 '23 at 18:52
  • @HansPassant: I'd rather have Windows take care of this. Otherwise I'd have to monitor that the Microsoft download links don't change, which of course they do, as you're probably fully aware. – Dave Doknjas Jan 13 '23 at 18:56
  • And it's not just the download links that will change. The script logic to determine whether .NET 7 is installed involve checking registry keys - again, something that could change in Windows updates. Between links and registry keys, I doubt that any script would work for more than a few months at a time. – Dave Doknjas Jan 13 '23 at 20:02

0 Answers0