Conversation
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This pull request updates the Flow Launcher project from .NET 9 to .NET 10 across the entire codebase.
Changes:
- Updated SDK version from 9.0 to 10.0 in global.json
- Updated target framework from net9.0 to net10.0 in all project files (.csproj)
- Updated CI/CD workflows to use .NET 10.0.x SDK
- Updated build scripts, publish profiles, and NuGet specification files to reference .NET 10
- Updated developer documentation in README.md
Reviewed changes
Copilot reviewed 28 out of 28 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| global.json | Updated SDK version from 9.0 to 10.0 |
| Flow.Launcher/Flow.Launcher.csproj | Updated target framework to net10.0-windows10.0.19041.0 |
| Flow.Launcher.Test/Flow.Launcher.Test.csproj | Updated target framework to net10.0-windows10.0.19041.0 |
| Flow.Launcher.Core/Flow.Launcher.Core.csproj | Updated target framework to net10.0-windows |
| Flow.Launcher.Infrastructure/Flow.Launcher.Infrastructure.csproj | Updated target framework to net10.0-windows |
| Flow.Launcher.Plugin/Flow.Launcher.Plugin.csproj | Updated target framework to net10.0-windows |
| Plugins/*.csproj (11 files) | Updated target framework to net10.0-windows or net10.0-windows10.0.19041.0 |
| Flow.Launcher/packages.lock.json | Updated framework key to net10.0-windows10.0.19041 |
| Flow.Launcher.Plugin/packages.lock.json | Updated framework key to net10.0-windows7.0 |
| Flow.Launcher.Infrastructure/packages.lock.json | Updated framework key to net10.0-windows7.0 |
| Flow.Launcher.Core/packages.lock.json | Updated framework key to net10.0-windows7.0 |
| Flow.Launcher/Properties/PublishProfiles/Net10.0-SelfContained.pubxml | Updated target framework and file reference |
| Scripts/post_build.ps1 | Updated publish profile path to Net10.0-SelfContained.pubxml |
| Scripts/flowlauncher.nuspec | Updated target path to lib\net10.0 |
| .github/workflows/dotnet.yml | Updated dotnet-version to 10.0.x |
| .github/workflows/default_plugins.yml | Updated dotnet-version and all framework references to net10.0 |
| README.md | Updated documentation to reference .NET 10 SDK and installation instructions |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
📝 WalkthroughWalkthroughRepository-wide upgrade of target framework and SDK from .NET 9 to .NET 10: workflows, global.json, project TargetFrameworks, lockfile dependency keys, publish profiles, packaging paths, build scripts, README, and CI adjustments updated accordingly. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Scripts/post_build.ps1 (1)
99-107:⚠️ Potential issue | 🟡 MinorRename
$profile— it shadows a PowerShell automatic variable.
$profileis a built-in automatic variable that holds the path to the current user's PowerShell profile script. Assigning to it in a function shadows the automatic variable for the rest of that session and can cause unexpected behavior in any downstream code (or if the script is dot-sourced) that depends on$profileto locate the profile file.🔧 Proposed fix
function Publish-Self-Contained ($p) { $csproj = Join-Path "$p" "Flow.Launcher/Flow.Launcher.csproj" -Resolve - $profile = Join-Path "$p" "Flow.Launcher/Properties/PublishProfiles/Net10.0-SelfContained.pubxml" -Resolve + $publishProfile = Join-Path "$p" "Flow.Launcher/Properties/PublishProfiles/Net10.0-SelfContained.pubxml" -Resolve # we call dotnet publish on the main project. # The other projects should have been built in Release at this point. - dotnet publish -c Release $csproj /p:PublishProfile=$profile + dotnet publish -c Release $csproj /p:PublishProfile=$publishProfile }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Scripts/post_build.ps1` around lines 99 - 107, The function Publish-Self-Contained assigns to the automatic PowerShell variable $profile which shadows the built-in and can break downstream code; rename that local to a safe identifier (e.g., $publishProfile or $pubxmlPath) and update its usage in the dotnet publish call, ensuring the variable passed to /p:PublishProfile matches the new name; leave $csproj as-is and only change references to $profile inside Publish-Self-Contained.
🧹 Nitpick comments (6)
Flow.Launcher.Core/Flow.Launcher.Core.csproj (1)
60-60:FSharp.Corestill pinned to the F# 9.0 version — should be updated for the .NET 10 migration.
FSharp.Core9.0.303 is the redistributable "For F# 9.0", while the current stable release is 10.0.103, described as "FSharp.Core redistributables from F# Tools version 14.0.103 For F# 10.0". Pinning the F# 9.0 redistributable while targetingnet10.0-windowsis inconsistent with the rest of the migration.📦 Suggested version bump
- <PackageReference Include="FSharp.Core" Version="9.0.303" /> + <PackageReference Include="FSharp.Core" Version="10.0.103" />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Flow.Launcher.Core/Flow.Launcher.Core.csproj` at line 60, The project still pins the FSharp.Core PACKAGE reference to version 9.0.303 which is inconsistent with the net10.0-windows migration; update the PackageReference for FSharp.Core in Flow.Launcher.Core.csproj (the <PackageReference Include="FSharp.Core" Version="..."/> entry) to the current stable redistributable version 10.0.103 so the project targets the F# 10 runtime.Flow.Launcher/Flow.Launcher.csproj (1)
147-148:Microsoft.Extensions.*packages not updated to 10.0.x alongside the .NET 10 migration.
Microsoft.Extensions.DependencyInjectionandMicrosoft.Extensions.Hostingare still pinned to9.0.9while all other projects are being bumped to .NET 10. The latest stable release ofMicrosoft.Extensions.Hostingis10.0.3, andMicrosoft.Extensions.DependencyInjection10.0.x is also available on NuGet. Keeping 9.0.x versions when the rest of the solution targetsnet10.0is an inconsistency that should be resolved in this same PR.📦 Suggested version bump
- <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="9.0.9" /> - <PackageReference Include="Microsoft.Extensions.Hosting" Version="9.0.9" /> + <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="10.0.3" /> + <PackageReference Include="Microsoft.Extensions.Hosting" Version="10.0.3" />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Flow.Launcher/Flow.Launcher.csproj` around lines 147 - 148, The project still references Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Hosting at Version="9.0.9"; update those PackageReference entries to the corresponding 10.0.x stable versions (e.g., 10.0.3 for Hosting and the matching 10.0.x for DependencyInjection) so they align with the net10.0 migration and other projects; locate the <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="9.0.9" /> and <PackageReference Include="Microsoft.Extensions.Hosting" Version="9.0.9" /> lines and change their Version attributes to the appropriate 10.0.x versions, then restore/verify the solution builds.Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj (1)
57-57:Microsoft.Windows.CsWin32bumped to0.3.269here but remains at0.3.205inFlow.Launcher.Infrastructure.
Microsoft.Windows.CsWin320.3.269is a valid NuGet package. However, sinceFlow.Launcher.Infrastructurealso depends on CsWin32 (at0.3.205) and both projects share the same solution, keeping the versions in sync avoids potential confusion. Consider aligning both to0.3.269.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj` at line 57, The two projects have mismatched Microsoft.Windows.CsWin32 versions: Flow.Launcher.Plugin.ProcessKiller references 0.3.269 while Flow.Launcher.Infrastructure remains at 0.3.205; update the PackageReference in the Flow.Launcher.Infrastructure .csproj (find the PackageReference with Include="Microsoft.Windows.CsWin32" and Version="0.3.205") to Version="0.3.269" so both projects match, then run a NuGet restore/build to verify no binding or API issues.Flow.Launcher/packages.lock.json (1)
87-125:Microsoft.Extensions.*packages remain pinned at 9.0.9 — consider bumping to 10.0.x.This lock file reflects
Version="9.0.9"declarations still present in the source.csprojfiles (not part of this PR's change set). While the 9.x packages are backward-compatible with .NET 10, upgrading them to the10.0.xequivalents (Microsoft.Extensions.Hosting,Microsoft.Extensions.DependencyInjection, etc.) completes the .NET 10 alignment and ensures any runtime-coupled fixes/improvements are included.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Flow.Launcher/packages.lock.json` around lines 87 - 125, The project is still referencing Microsoft.Extensions.* packages at 9.0.9 (e.g., Microsoft.Extensions.Hosting and Microsoft.Extensions.DependencyInjection); update the PackageReference entries in your .csproj files to 10.0.x for those packages (and any other Microsoft.Extensions.* references), then run dotnet restore (or delete packages.lock.json and run restore) to regenerate the lock file so packages.lock.json reflects 10.0.x; finally build and run tests to ensure no API changes require code adjustments in types/methods like HostBuilder/ServiceCollection usages.Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj (1)
52-52: UpdateSystem.Data.OleDbto version 10.0.3 for consistency with .NET 10 target framework.
System.Data.OleDb10.0.3 is now available and compatible withnet10.0-windows. Updating keeps the dependency version aligned with the target framework version.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj` at line 52, Update the PackageReference for System.Data.OleDb in the project file: locate the PackageReference element with Include="System.Data.OleDb" (currently Version="9.0.9") and change its Version attribute to "10.0.3" so the dependency aligns with the net10.0-windows target framework.Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj (1)
67-67: Consider bumpingMicrosoft.Extensions.Caching.Memoryto version10.0.3.Version
9.0.9is stale; the latest stable release is10.0.3. Updating aligns the dependency with current stable releases and picks up any .NET 10–specific runtime improvements.📦 Suggested update
- <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="9.0.9" /> + <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="10.0.3" />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj` at line 67, Replace the PackageReference that currently pins Microsoft.Extensions.Caching.Memory at Version="9.0.9" with the newer Version="10.0.3" in the project file; locate the PackageReference entry for Microsoft.Extensions.Caching.Memory and update its Version attribute to "10.0.3" (and if the project targets an older framework, ensure target framework compatibility after the update).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 423: The link text "here" in the README line 'Manually from
[here](https://dotnet.microsoft.com/en-us/download/dotnet/10.0)' is
non-descriptive; update that markdown to use meaningful link text (e.g.,
"Microsoft .NET 10 download page" or "Download .NET 10") so the link is
understandable out of context and satisfies MD059, replacing the "[here](...)"
token accordingly.
---
Outside diff comments:
In `@Scripts/post_build.ps1`:
- Around line 99-107: The function Publish-Self-Contained assigns to the
automatic PowerShell variable $profile which shadows the built-in and can break
downstream code; rename that local to a safe identifier (e.g., $publishProfile
or $pubxmlPath) and update its usage in the dotnet publish call, ensuring the
variable passed to /p:PublishProfile matches the new name; leave $csproj as-is
and only change references to $profile inside Publish-Self-Contained.
---
Nitpick comments:
In `@Flow.Launcher.Core/Flow.Launcher.Core.csproj`:
- Line 60: The project still pins the FSharp.Core PACKAGE reference to version
9.0.303 which is inconsistent with the net10.0-windows migration; update the
PackageReference for FSharp.Core in Flow.Launcher.Core.csproj (the
<PackageReference Include="FSharp.Core" Version="..."/> entry) to the current
stable redistributable version 10.0.103 so the project targets the F# 10
runtime.
In `@Flow.Launcher/Flow.Launcher.csproj`:
- Around line 147-148: The project still references
Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Hosting at
Version="9.0.9"; update those PackageReference entries to the corresponding
10.0.x stable versions (e.g., 10.0.3 for Hosting and the matching 10.0.x for
DependencyInjection) so they align with the net10.0 migration and other
projects; locate the <PackageReference
Include="Microsoft.Extensions.DependencyInjection" Version="9.0.9" /> and
<PackageReference Include="Microsoft.Extensions.Hosting" Version="9.0.9" />
lines and change their Version attributes to the appropriate 10.0.x versions,
then restore/verify the solution builds.
In `@Flow.Launcher/packages.lock.json`:
- Around line 87-125: The project is still referencing Microsoft.Extensions.*
packages at 9.0.9 (e.g., Microsoft.Extensions.Hosting and
Microsoft.Extensions.DependencyInjection); update the PackageReference entries
in your .csproj files to 10.0.x for those packages (and any other
Microsoft.Extensions.* references), then run dotnet restore (or delete
packages.lock.json and run restore) to regenerate the lock file so
packages.lock.json reflects 10.0.x; finally build and run tests to ensure no API
changes require code adjustments in types/methods like
HostBuilder/ServiceCollection usages.
In `@Plugins/Flow.Launcher.Plugin.Explorer/Flow.Launcher.Plugin.Explorer.csproj`:
- Line 52: Update the PackageReference for System.Data.OleDb in the project
file: locate the PackageReference element with Include="System.Data.OleDb"
(currently Version="9.0.9") and change its Version attribute to "10.0.3" so the
dependency aligns with the net10.0-windows target framework.
In
`@Plugins/Flow.Launcher.Plugin.ProcessKiller/Flow.Launcher.Plugin.ProcessKiller.csproj`:
- Line 57: The two projects have mismatched Microsoft.Windows.CsWin32 versions:
Flow.Launcher.Plugin.ProcessKiller references 0.3.269 while
Flow.Launcher.Infrastructure remains at 0.3.205; update the PackageReference in
the Flow.Launcher.Infrastructure .csproj (find the PackageReference with
Include="Microsoft.Windows.CsWin32" and Version="0.3.205") to Version="0.3.269"
so both projects match, then run a NuGet restore/build to verify no binding or
API issues.
In `@Plugins/Flow.Launcher.Plugin.Program/Flow.Launcher.Plugin.Program.csproj`:
- Line 67: Replace the PackageReference that currently pins
Microsoft.Extensions.Caching.Memory at Version="9.0.9" with the newer
Version="10.0.3" in the project file; locate the PackageReference entry for
Microsoft.Extensions.Caching.Memory and update its Version attribute to "10.0.3"
(and if the project targets an older framework, ensure target framework
compatibility after the update).
Cleaned up PluginsManagerSettings.xaml and SettingsControl.xaml by removing empty <Grid.ColumnDefinitions /> elements. This reduces unnecessary markup since only row definitions are used.
The System.Linq.Async dependency was removed from the Explorer project file as it is no longer required.
Added a script step to download and install .NET SDK 10.0.100 using dotnet-install.ps1, addressing missing SDK in VS2022 image. References AppVeyor issue regarding SDK availability.
|
🥷 Code experts: jjw24 jjw24, Jack251970 have most 👩💻 activity in the files. See details
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame:
Activity based on git-commit:
Knowledge based on git-blame: ✨ Comment |
Changed development instructions to require Visual Studio 2026 (v18.0+) instead of Visual Studio 2022 (v17.12+).
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@appveyor.yml`:
- Around line 19-21: Add a SHA-256 integrity check before executing the
downloaded dotnet-install.ps1: after Invoke-WebRequest (which writes to
"$env:temp\dotnet-install.ps1") compute the file's SHA-256 and compare it to a
pinned known-good hash, and only run "& $env:temp\dotnet-install.ps1
-Architecture x64 -Version '10.0.100' -InstallDir "$env:ProgramFiles\dotnet"" if
the hash matches; if it does not match, fail the build with a clear error
message. Reference the existing Invoke-WebRequest call, the downloaded file path
"$env:temp\dotnet-install.ps1", and the execution invocation (&
$env:temp\dotnet-install.ps1) when adding the verification and failure logic.
- Line 21: Update the pinned .NET SDK version in the dotnet installer
invocation: replace the current -Version '10.0.100' used with dotnet-install.ps1
with -Version '10.0.103' so the pipeline uses the patched SDK (reference the
command invoking dotnet-install.ps1 and the -Version '10.0.100' token to locate
the change).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 416: Replace the incorrect branding ".Net 10" with the official ".NET 10"
in the README; specifically update the phrase "Flow Launcher's target framework
is .Net 10" and any other occurrences (e.g., the instance around line 420) so
they read "Flow Launcher's target framework is .NET 10".
---
Duplicate comments:
In `@README.md`:
- Line 423: Replace the non-descriptive link text "here" with meaningful text
such as "Microsoft .NET 10.0 download page" so the link is understandable out of
context; update the README.md link target line that currently reads "Manually
from [here](https://dotnet.microsoft.com/en-us/download/dotnet/10.0)" to use
descriptive anchor text (e.g., "Manually from the Microsoft .NET 10.0 download
page") while keeping the same URL.
1 participant
Summary by cubic
Upgrade Flow Launcher, tests, and all default plugins to .NET 10 and update CI, packaging, and docs to use the 10.0 SDK. Solves the repo-wide .NET 10 migration; context is aligning the toolchain and targets across app, plugins, and workflows; closes the .NET 10 upgrade tracking issue.
Migration
Refactors
Written for commit ff3fb5d. Summary will update on new commits.