Позволю себе немного не согласиться
NET6 (на котором я на данный момент сижу), и, подозреваю, NET8 - совершенно другая платформа.
Действительно, многое, что в NET FrameWork было "из коробки", придется доставлять NuGet-пакетами (там не только реестр, но и кодировки файлов, и овердофига чего еще). Насчет совместимости ничего сказать не могу - пока не сталкивался.
Новый проект можно не создавать с нуля, а пробросить связь (Link) на старый проект. Т.е. в одном решении будет сразу два проекта - один под FrameWork, второй под NET8.
Вытаскивать из NuGet ничего не надо. Для предоставления конечным пользователям можно использовать AssemblyResolve в инициализаторе. И выполнять не сборку, а публикацию проекта. Ну или в cspoj руками прописать как ты и сделал:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
По крайней мере у меня оно работает.
Работу с SQL, возможно, будет иметь смысл переложить на EntityFramework (который вообще положить в отдельную сборку NET Standard 2.0 для совместного использования в NET Framework и NET8). Тогда и с клиентами особо можно не заморачиваться
Версию сборки также можно руками прописать в csproj:
<Version>1.2.3.4</Version>
После этого и в GUI MS VS станет доступным соответствующее поле.
Для использования в проекте WinForms достаточно прописать как и у тебя:
<UseWindowsForms>true</UseWindowsForms>
Для использования WPF - соответственно
<UseWPF>true</UseWPF>
Насчет ресурсов ничего не скажу, пока не требовалось. А ресурсные библиотеки под меню у меня все равно в отдельном проекте болтаются...
---
Согласен, что многое (если не все) непривычно и далеко не всегда очевидно. Но все же решаемо ИМХО