activescott
(FEEDBACK WANTED): Support .NET 8 and .NET Standard 2.0
@mega5800 I was contacted by a lessmsi user who has migrated lessmsi to .NET 8 and .NET Standard 2.0 (maybe also see https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting) and provided me access to his code changes. I think this is valuable to contributors if we just keep lessmsi using the latest platform libraries, but honestly I'm not very confident.
Do you think it's valuable to users and/or contributors if we migrate lessmsi to .NET 8 and .NET Standard 2.0?
Would it still work on the operating systems we support according to the Supported Windows Versions section of the README?
If so, are you interested in contributing it? Happy to provide you access to his code (and he also said that would be fine).
Hi @activescott. Thank you for considering my input for this valuable suggestion.
We are currently using .Net 4.8, which is supported on the next os:
Client Operating Systems: Windows 10 (version 1507 and later) Windows 8.1 Windows 7 SP1
Server Operating Systems: Windows Server 2025 Windows Server 2022 Windows Server 2019 Windows Server, version 1709, 1803, 1809 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 SP1 Windows Server 2008 SP2
From what I could find, .Net 8 is supported by a shorter list of OS: Windows 11 Windows 10 (version 1909 or later) Windows Server 2022, 2019, and 2016
This is an obvious decision between supporting existing users and upgrading the utilised .net version. From one hand, migrating to .Net 8 might break LessMSI for clients with legacy systems. From the other hand, however, we will leverage the benefits of .Net 8 by using it as the framework for LessMSI.
I think the best approach would be to split LessMSI into two versions - Legacy & Current versions. The legacy version will be based on .Net 4.8 for legacy users, where as the current version will be based on the latest LTS .net version (could be .Net 8 now or something else in the future).
Please let me know your thoughts about this suggestion.
Moving to .NET Standard 2.0 isn’t much of an upgrade, it still leans on .NET Framework patterns and APIs.
Just bumping the project to .NET 8 won’t magically improve performance or clean up legacy code. Without proper refactoring, you’re likely to end up with the same technical debt, just on a newer runtime.
Also .NET 8 hits end-of-support next year. If you're planning a shift to .NET Core, it makes more sense to aim for .NET 10, which will be an LTS release and give the project a longer runway.
I don't think performance or removing "legacy code" are really the goals of upgrading (at least from my perspective). I consider the goals to be the following:
- At runtime it works immediately, easily, and securely on the supported versions of Windows according to our Windows Support policy at https://github.com/activescott/lessmsi#supported-windows-versions
- Make it easy for new and existing .NET developers to come in and modify lessmsi. That means it continues to be easy to clone the repo and make changes using current common tooling used for .NET development (i.e. Visual Studio).
If supporting "supported" versions of Windows or current tooling means that users commonly using lessmsi on legacy Windows versions are affected, we can bump the major version of lessmsi and encourage those users to download a "legacy" version of lessmsi for legacy versions of windows and allow the current major version of lessmsi to support the latest version of windows.
Again, open to suggestions here!
At runtime it works immediately, easily, and securely on the supported versions of Windows according to our Windows Support policy at https://github.com/activescott/lessmsi#supported-windows-versions
Unlike .NET Framework, modern .NET requires users to install a specific runtime, which conflicts with your stated policies and logic, especially considering that .NET Framework 4.8.1 has been included in Windows 10 via Windows Update and refreshed ISOs since 2023.
Make it easy for new and existing .NET developers to come in and modify lessmsi. That means it continues to be easy to clone the repo and make changes using current common tooling used for .NET development (i.e. Visual Studio).
From a development perspective, there's no significant difference: Visual Studio 2026 continues to support .NET Framework 4.8 out of the box.
The real value in targeting modern .NET would come from a deliberate migration and refactoring of the codebase. Such an effort could modernize the project, improve maintainability, and ensure long-term support.
It's also worth noting that both .NET Standard 2.1 and .NET Framework are in maintenance mode.
From my perspective, if there's no intention to modernize the project or refactor the codebase to .NET, the most straightforward path would be to upgrade to .NET Framework 4.8.1 and not .NET Standard 2.0/.NET 8.0 (one being already obsolete, and the other will be out of support next year).
@mega5800 As I mentioned in #242, I actually see value in upgrading the .NET version for better maintenance for new features such as Dark Mode (but not limited to that, I'm sure others will come up). Here is some more information:
According to https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#cadence the only supported versions of .NET are .NET 8, .NET 9, and .NET 10. So it seems we should be on one of those and we shouldn't choose the oldest one 🙂 According to .NET Supported OS Policy (also linked from the page above) .NET 9 supports Windows 10+ and .NET 10 is Windows 11+ only.
Also noteworthy is that according to https://learn.microsoft.com/en-us/windows/release-health/supported-versions-windows-client Microsoft no longer supports Windows 10. So I think if we want, we can have Lessmsi's new releases declare that all future versions only support Windows 11 or greater. We don't have to do that of course but we can if supporting Windows 10 becomes inconvenient (e.g. preventing us from upgrading .NET). To do so, we'd just increment the major version (2.x → 3.x) and explicitly call it out in the release notes that it won't be supported in Windows 10 going forward (Windows 10 users can download the old version or use it at their own risk). We can wait until we decide it's necessary.
So, I think before implementing #242, we should upgrade to .NET 9 or .NET 10 and get the support for Dark Mode from that. As you know, Lessmsi has some deep dependencies on native DLLs for MSI and Cab support, but if that becomes a blocker or a challenge as part of the upgrade, I can commit to you that I'll do the work to port it or make it work.
Keep in mind that .NET 10 and Visual Studio 2026 are compatible with Windows 10. However, Microsoft cannot publicly declare support for an operating system that has reached EOL.
I strongly recommend targeting LTS releases such as .NET 10, which will receive updates for three years. By contrast, .NET 9 will reach end of support next year, alongside .NET 8.
The attached quick report, shows issues identified for the migration to .NET 10, including unsupported code and dependencies, identified by Visual Studio (most of which just noise honestly, but the dependencies one is worth looking at).