-
-
Notifications
You must be signed in to change notification settings - Fork 446
update to .net 9 #3286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update to .net 9 #3286
Conversation
This comment has been minimized.
This comment has been minimized.
🥷 Code experts: jjw24 jjw24 has most 🧠 knowledge in the files. See details
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
📝 Walkthrough## Walkthrough
This update upgrades the entire Flow Launcher solution—including core, infrastructure, plugins, and tests—from .NET 7.0 to .NET 9.0. Project files, build scripts, CI workflows, and documentation are updated accordingly. New `packages.lock.json` files are introduced for dependency locking, and minor resource path corrections are made.
## Changes
| Files/Paths | Change Summary |
|---------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|
| `Flow.Launcher.Core/Flow.Launcher.Core.csproj`, `Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj`, `Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj`, `Flow.Launcher/Flow.Launcher.csproj`, `Flow.Launcher.Test/Flow.Launcher.Test.csproj`, `Plugins/.../*.csproj` | Updated `<TargetFramework>` from .NET 7.0 to .NET 9.0 in all project files; some added `<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>`. |
| `Flow.Launcher/Flow.Launcher.csproj` | Fixed font resource path: `"Segoe Fluent Icons.ttf"` → `"SegoeFluentIcons.ttf"`. |
| `README.md` | Updated SDK installation instructions and URLs from .NET 7 to .NET 9. |
| `Scripts/flowlauncher.nuspec` | Changed target framework in package structure from `net7.0` to `net9.0`. |
| `Scripts/post_build.ps1` | Updated publish profile reference from Net7.0 to Net9.0. |
| `Flow.Launcher/Properties/PublishProfiles/Net9.0-SelfContained.pubxml` | Updated target framework from `net7.0-windows10.0.19041.0` to `net9.0-windows10.0.19041.0`. |
| `Flow.Launcher.Core/packages.lock.json`, `Flow.Launcher.Infrastructure/packages.lock.json`, `Flow.Launcher.Plugin/packages.lock.json`, `Flow.Launcher/packages.lock.json` | Added new lock files for dependency versioning. |
| `.github/workflows/default_plugins.yml`, `.github/workflows/dotnet.yml` | Updated CI workflows to use .NET 9.0 SDK and publish for net9.0-windows targets. |
| `global.json` | Changed SDK version from 7.0.* to 9.0.*. |
## Sequence Diagram(s)
_Not applicable for this set of changes, as they are project configuration and dependency updates without new or modified runtime control flow._
## Possibly related PRs
- [Flow-Launcher/Flow.Launcher#3328](https://github.com/Flow-Launcher/Flow.Launcher/pull/3328): Reverts a package version upgrade in the Explorer plugin due to .NET 7 compatibility, which is related as both PRs address .NET version targeting and package compatibility.
## Suggested reviewers
- taooceros
- jjw24 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
Flow.Launcher.Core/Flow.Launcher.Core.csproj
(1 hunks)Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
(1 hunks)Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj
(1 hunks)Flow.Launcher.Test/Flow.Launcher.Test.csproj
(1 hunks)Flow.Launcher/Flow.Launcher.csproj
(1 hunks)Flow.Launcher/Properties/PublishProfiles/Net7.0-SelfContained.pubxml
(0 hunks)Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Calculator/Flow.Launcher.Plugin.Calculator.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.PluginIndicator/Flow.Launcher.Plugin.PluginIndicator.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/Flow.Launcher.Plugin.PluginsManager.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Shell/Flow.Launcher.Plugin.Shell.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.Url/Flow.Launcher.Plugin.Url.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.WebSearch/Flow.Launcher.Plugin.WebSearch.csproj
(1 hunks)Plugins/Flow.Launcher.Plugin.WindowsSettings/Flow.Launcher.Plugin.WindowsSettings.csproj
(1 hunks)README.md
(1 hunks)Scripts/flowlauncher.nuspec
(1 hunks)Scripts/post_build.ps1
(1 hunks)
💤 Files with no reviewable changes (1)
- Flow.Launcher/Properties/PublishProfiles/Net7.0-SelfContained.pubxml
🧰 Additional context used
🧠 Learnings (4)
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj (1)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-11-12T03:58:56.325Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher/Flow.Launcher.csproj (1)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-11-12T03:58:56.325Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher.Core/Flow.Launcher.Core.csproj (1)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-11-12T03:58:56.325Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Flow.Launcher.Test/Flow.Launcher.Test.csproj (1)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-11-12T03:58:56.325Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: gitStream.cm
🔇 Additional comments (19)
Scripts/flowlauncher.nuspec (1)
14-14
: Target framework correctly updated to .NET 9The target path has been properly updated from
net7.0
tonet9.0
, which aligns with the overall objective of updating the project to .NET 9.Plugins/Flow.Launcher.Plugin.Url/Flow.Launcher.Plugin.Url.csproj (1)
5-5
: Target framework correctly updated to .NET 9The TargetFramework has been properly updated from
net7.0-windows
tonet9.0-windows
, which aligns with the PR's objective of upgrading to .NET 9.Plugins/Flow.Launcher.Plugin.WindowsSettings/Flow.Launcher.Plugin.WindowsSettings.csproj (1)
4-4
: Target framework correctly updated to .NET 9The TargetFramework has been properly updated from
net7.0-windows
tonet9.0-windows
, which aligns with the PR's objective of upgrading to .NET 9.Plugins/Flow.Launcher.Plugin.Shell/Flow.Launcher.Plugin.Shell.csproj (1)
5-5
: Target framework correctly updated to .NET 9The TargetFramework has been properly updated from
net7.0-windows
tonet9.0-windows
, which aligns with the PR's objective of upgrading to .NET 9.Plugins/Flow.Launcher.Plugin.WebSearch/Flow.Launcher.Plugin.WebSearch.csproj (1)
5-5
: Target Framework Update VerificationThe
<TargetFramework>
element has been successfully updated tonet9.0-windows
. This change is fully aligned with the project's upgrade objective to .NET 9.Plugins/Flow.Launcher.Plugin.Calculator/Flow.Launcher.Plugin.Calculator.csproj (1)
5-5
: Target Framework Update VerificationThe
<TargetFramework>
element now specifiesnet9.0-windows
, which is consistent with the overall upgrade to .NET 9. Please ensure that all referenced dependencies and project integrations remain compatible with the new framework version.Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj (1)
5-5
: Framework Upgrade ConfirmationThe project file now targets
net9.0-windows
, confirming the migration from .NET 7. This update is consistent with the other projects in the solution, ensuring uniformity across the ecosystem.Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj (1)
5-5
: Target Framework Update ConfirmationThe
<TargetFramework>
is updated tonet9.0-windows
, which aligns with the broader project upgrade to .NET 9. Verify that all project references and any version-specific features in dependencies continue to function as expected with this change.Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj (1)
5-5
: Framework upgrade looks good.The upgrade from .NET 7 to .NET 9 is properly implemented. I notice that the package reference to Microsoft.Extensions.Caching.Memory (line 67) is already at version 9.0.0, which aligns correctly with the .NET 9 framework.
Scripts/post_build.ps1 (1)
102-102
: Publish profile path correctly updated.The path has been appropriately updated to reference the .NET 9 publish profile instead of the .NET 7 one, which aligns with the framework upgrade.
Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj (1)
4-4
: Framework upgrade looks good.The target framework has been properly updated from .NET 7 to .NET 9, maintaining consistency with the other project files in the solution.
Plugins/Flow.Launcher.Plugin.Sys/Flow.Launcher.Plugin.Sys.csproj (1)
5-5
: Framework upgrade looks good.The target framework has been properly updated from .NET 7 to .NET 9, consistent with the other project files in the solution.
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj (1)
4-4
: Target Framework Update Verified in Infrastructure Project.
The update to<TargetFramework>net9.0-windows</TargetFramework>
is in line with the overall migration to .NET 9. Please ensure that all WPF components and referenced packages are compatible with .NET 9.Flow.Launcher.Core/Flow.Launcher.Core.csproj (1)
4-4
: Target Framework Updated in Core Project.
Changing the target framework to<TargetFramework>net9.0-windows</TargetFramework>
correctly aligns with the broader upgrade. All related properties (such as enabling both WPF and Windows Forms) remain consistent.Plugins/Flow.Launcher.Plugin.PluginsManager/Flow.Launcher.Plugin.PluginsManager.csproj (1)
4-4
: PluginsManager Target Framework Update.
The update to<TargetFramework>net9.0-windows</TargetFramework>
ensures consistency with the overall .NET 9 migration. Please verify that all plugin-specific dependencies and settings continue to function as expected under the new framework.Plugins/Flow.Launcher.Plugin.BrowserBookmark/Flow.Launcher.Plugin.BrowserBookmark.csproj (1)
5-5
: BrowserBookmark Plugin Framework Upgrade.
The updated<TargetFramework>net9.0-windows</TargetFramework>
meets the new .NET 9 requirements. The project configuration, including output and copying settings, appears correct.Plugins/Flow.Launcher.Plugin.PluginIndicator/Flow.Launcher.Plugin.PluginIndicator.csproj (1)
5-5
: PluginIndicator Target Framework Update.
The change to<TargetFramework>net9.0-windows</TargetFramework>
is consistent with the migration objectives. Ensure that all package references and any inter-project dependencies have been validated for .NET 9 compatibility.Flow.Launcher.Test/Flow.Launcher.Test.csproj (1)
4-4
: Target Framework Update in Test Project
The<TargetFramework>
element is updated tonet9.0-windows10.0.19041.0
, aligning the test project with the overall .NET 9 upgrade. Please verify that all tests run correctly under the new runtime.Flow.Launcher/Flow.Launcher.csproj (1)
5-5
: Updated Target Framework for Main Launcher Project
The<TargetFramework>
element has been updated tonet9.0-windows10.0.19041.0
to reflect the migration to .NET 9. This change is crucial for leveraging the latest runtime features and performance improvements. Additionally, with the removal of the outdated comment regarding upgrading Microsoft.Extensions libraries, please ensure that the current package versions (e.g., for Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Hosting, both at version 7.0.0) are fully compatible with .NET 9.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hello, do you think we need to fix this build issue - ambiguous reference between 'System.Windows.Controls.ContextMenu' and 'System.Windows.Forms.ContextMenu' from #3234? |
.net 10 seems to be pretty far away (at least another half year). I guess we can fix it in a separate pr. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
.github/workflows/dotnet.yml (1)
42-46
: Locked-mode is ineffective while usingnuget restore
; switch todotnet restore --locked-mode
The PR description highlights adoption of dependency Locked mode, but the workflow still calls the classic NuGet CLI:
- run: nuget restoreNuGet.exe ignores
packages.lock.json
lock-mode flags. Use the SDK-based restore instead:- - name: Restore dependencies - run: nuget restore + - name: Restore dependencies + run: dotnet restore --locked-modeThis guarantees CI fails when the lock file is out-of-date and makes the restore step framework-aware.
🧹 Nitpick comments (1)
.github/workflows/dotnet.yml (1)
35-40
: Re-enable the built-in NuGet cache for faster CI runs
actions/setup-dotnet@v4
can automatically cache the global NuGet package folder, but the relevant
configuration is commented out. Re-enabling saves ~1-2 min per run:-# cache: true -# cache-dependency-path: | -# Flow.Launcher/packages.lock.json -# Flow.Launcher.Core/packages.lock.json -# Flow.Launcher.Infrastructure/packages.lock.json -# Flow.Launcher.Plugin/packages.lock.json + cache: true + cache-dependency-path: | + **/packages.lock.jsonWildcard keeps maintenance low as more projects adopt lock files.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/default_plugins.yml
(13 hunks).github/workflows/dotnet.yml
(1 hunks)global.json
(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- global.json
- .github/workflows/default_plugins.yml
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3572
File: Flow.Launcher/App.xaml.cs:214-216
Timestamp: 2025-07-06T12:21:37.947Z
Learning: In Flow Launcher, the UpdatePluginManifestAsync method in PluginsManifest.cs already has comprehensive internal try-catch handling that logs exceptions and returns false on failure rather than throwing, making external try-catch wrappers unnecessary.
Learnt from: Jack251970
PR: Flow-Launcher/Flow.Launcher#3561
File: Flow.Launcher/ViewModel/SelectBrowserViewModel.cs:53-58
Timestamp: 2025-05-21T10:37:07.696Z
Learning: When implementing collection item removal operations in Flow Launcher, always handle index boundaries carefully. After removing an item from a collection, ensure the updated index remains within valid bounds (>= 0 and < collection.Count) to prevent IndexOutOfRangeExceptions, especially when decrementing indexes.
Learnt from: Yusyuriv
PR: Flow-Launcher/Flow.Launcher#3057
File: Flow.Launcher.Core/Plugin/JsonRPCPluginSettings.cs:0-0
Timestamp: 2024-11-03T07:40:11.014Z
Learning: In Flow Launcher, when using Windows Forms dialogs (e.g., in `JsonRPCPluginSettings.cs`), path validation is enabled by default in `OpenFileDialog` and `FolderBrowserDialog`, preventing users from selecting invalid paths, but it's possible to opt out of this validation on individual dialogs.
.github/workflows/dotnet.yml (1)
Learnt from: taooceros
PR: Flow-Launcher/Flow.Launcher#2616
File: Flow.Launcher/Flow.Launcher.csproj:7-7
Timestamp: 2024-10-08T15:52:58.573Z
Learning: In the Flow Launcher project, the version number in the `Flow.Launcher.csproj` file is dynamically updated during the CI/CD process.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
.github/workflows/dotnet.yml (1)
31-35
: .NET 9 preview/G.A. availability needs an explicit pin or matching global.json to avoid drift
dotnet-version: 9.0.x
will always float to the latest 9.0.* SDK that exists at workflow-run time.
If the repo’sglobal.json
pins a different preview/patch (or none at all), local dev and CI may diverge.Consider either:
- dotnet-version: 9.0.x + dotnet-version: 9.0.100 # or the exact build used in global.json +# dotnet-quality: "preview" # only if still on preview bitsor ensure
global.json
is checked-in and already pins9.0.x
so both environments resolve identically.
This prevents the “it builds on my machine but not on CI” class of version mismatches.
Done |
Thanks! |
Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj
Outdated
Show resolved
Hide resolved
Hmm on second thought we probably don't want to put through the readme changes, better to have the readme done in a separate PR because it might mislead plugin devs to think Flow is already out with .Net 9 since dev branch is the default landing page. I will split out readme changes to a separate PR. |
Agree |
We have experienced various issue with outdated framework, and also .Net 9 provides an excited theme for WPF, which we could later use to improve our UI.
Additional Change:
Segoe Font Icons still have some problem (which is probably why .net 8 is paused)(Remove the space in the file name makes it work).