-
-
Notifications
You must be signed in to change notification settings - Fork 254
Update project dependencies (#11089) #11090
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
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis set of changes updates various project files across the repository to increment versions of Microsoft and related NuGet packages from 9.0.6 to 9.0.7, and other dependencies to their latest patch releases. It also updates the .NET SDK version to 9.0.302 and bumps the esbuild devDependency in multiple package.json files. Changes
Assessment against linked issues
Poem
✨ Finishing Touches🧪 Generate unit tests
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.
Pull Request Overview
This PR updates the project’s SDK, NuGet package references, and frontend build tools to the latest patch versions and adds two Boilerplate server projects to the CI solution.
- Bump global SDK from 9.0.301 to 9.0.302
- Upgrade Microsoft.* and related NuGet packages from 9.0.6 to 9.0.7 across all projects
- Update esbuild devDependency to 0.25.6 in client package.json files
- Add two new Boilerplate server projects to the CI solution
Reviewed Changes
Copilot reviewed 40 out of 50 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/global.json | Bump SDK version to 9.0.302 |
| package.json (all client folders) | Bump esbuild devDependency to 0.25.6 |
| *.csproj (Shared/Server/Client projects across Websites/Careers/Platform) | Update Microsoft.* package references to 9.0.7 |
| src/Templates/Boilerplate/.../Directory.Packages.props | Upgrade numerous package versions to 9.0.7 |
| src/Templates/Boilerplate/.../AppDbContextModelSnapshot.cs | Update EF Core model snapshot annotation |
| src/Templates/Boilerplate/.../dotnet-tools.json | Bump dotnet-ef tool version to 9.0.7 |
| src/Bit-CI.slnx | Add Boilerplate.Server.AppHost and .Server.Shared projects |
Files not reviewed (10)
- src/BlazorUI/Bit.BlazorUI.Extras/package-lock.json: Language not supported
- src/BlazorUI/Bit.BlazorUI/package-lock.json: Language not supported
- src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/package-lock.json: Language not supported
- src/Bswup/Bit.Bswup/package-lock.json: Language not supported
- src/Butil/Bit.Butil/package-lock.json: Language not supported
- src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/package-lock.json: Language not supported
- src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Data/Migrations/20250702084958_Initial.Designer.cs: Language not supported
- src/Websites/Careers/src/Bit.Websites.Careers.Client/package-lock.json: Language not supported
- src/Websites/Platform/src/Bit.Websites.Platform.Client/package-lock.json: Language not supported
- src/Websites/Sales/src/Bit.Websites.Sales.Client/package-lock.json: Language not supported
Comments suppressed due to low confidence (1)
src/Bit-CI.slnx:131
- The solution file now references Boilerplate.Server.AppHost and Boilerplate.Server.Shared, but I don't see those project files added in this PR. Please ensure the corresponding .csproj files are committed so the solution builds correctly.
<Project Path="Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.AppHost/Boilerplate.Server.AppHost.csproj" />
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: 4
♻️ Duplicate comments (8)
src/BlazorUI/Bit.BlazorUI.Extras/package.json (1)
3-3: See previous esbuild comment – same considerations applysrc/Websites/Careers/src/Bit.Websites.Careers.Client/package.json (1)
3-3: See previous esbuild comment – same considerations applysrc/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/package.json (1)
3-3: See previous esbuild comment – same considerations applysrc/Websites/Sales/src/Bit.Websites.Sales.Client/package.json (1)
3-3: Sameesbuildpatch update as other packages – comment duplicated.src/BlazorUI/Bit.BlazorUI/package.json (1)
3-3: Sameesbuildpatch update as other packages – comment duplicated.src/Bswup/Bit.Bswup/package.json (1)
3-3: Sameesbuildpatch update as other packages – comment duplicated.src/Websites/Careers/src/Bit.Websites.Careers.Server/Bit.Websites.Careers.Server.csproj (1)
14-17: Same note as Sales.Server: double-check that WebAssembly packages are truly needed.See previous comment for rationale.
src/Websites/Platform/src/Bit.Websites.Platform.Server/Bit.Websites.Platform.Server.csproj (1)
14-17: Verify necessity of client-side packages in server project.Same concern as in Sales & Careers servers.
🧹 Nitpick comments (12)
src/Websites/Platform/src/Bit.Websites.Platform.Shared/Bit.Websites.Platform.Shared.csproj (1)
17-19: Prefer central package version management over per-project declarationsHard-coding the same
9.0.7version in every.csprojinvites drift at the next upgrade cycle. Placing these versions in a solution-levelDirectory.Packages.props(orPackageVersions.props) lets you bump them once for the whole repo and keeps IntelliSense warnings in sync.Example of what the diff inside this file would look like after moving versions centrally:
-<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="9.0.7" /> +<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" /> -<PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="9.0.7" /> +<PackageReference Include="Microsoft.Extensions.Configuration.Binder" /> -<PackageReference Include="System.Text.Json" Version="9.0.7" /> +<PackageReference Include="System.Text.Json" />No functional change required now, but worth scheduling before the next wave of upgrades.
src/Websites/Sales/src/Bit.Websites.Sales.Shared/Bit.Websites.Sales.Shared.csproj (1)
17-19: Duplicate version strings — centralize to avoid future driftSame rationale as the Platform project: lift
9.0.7into aDirectory.Packages.propsso that Sales, Platform, Careers, etc. stay aligned automatically.src/Websites/Careers/src/Bit.Websites.Careers.Shared/Bit.Websites.Careers.Shared.csproj (1)
17-19: Reduce maintenance by moving versions to a props fileMirrors the earlier comments; consider removing the
Versionattributes here and managing them centrally.src/Bswup/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo.csproj (1)
9-12: Consider centralising package versions.Instead of hard-coding the patch version in every project file, migrate common packages to a
Directory.Packages.props(orGlobalPackages.props) so future patch bumps become one-liner changes.src/BlazorUI/Demo/Bit.BlazorUI.Demo.Shared/Bit.BlazorUI.Demo.Shared.csproj (1)
16-19: Centralise common package versions to cut future maintenance
Bumping fourMicrosoft.*&System.Text.Jsonreferences to 9.0.7 is fine, but the repo now contains the same version string in dozens of.csprojfiles. Consider moving these to aDirectory.Packages.props(NuGet-style central package management) or a shared MSBuild property to avoid manual, error-prone mass edits next time.src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Windows/Bit.BlazorUI.Demo.Client.Windows.csproj (1)
41-41: Consider centralizing the package version
Hard-coding9.0.7here—and in many sibling projects—means the next bump requires touching every .csproj. Place the version inDirectory.Packages.propsor expose it via a$(Microsoft_AspNetCore_Components_Web_Version)property to keep updates atomic.src/Bswup/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo.Client/Bit.Bswup.NewDemo.Client.csproj (1)
17-17: Same duplication concern as in other projects
Extract theMicrosoft.AspNetCore.Components.WebAssemblyversion into a shared props/props-style file and drop theVersion=attribute here to prevent drift across projects.src/BlazorUI/Demo/Bit.BlazorUI.Demo.Server/Bit.BlazorUI.Demo.Server.csproj (1)
29-29: CentralizeMicrosoft.AspNetCore.Components.WebAssembly.Serverversion
Keeping the version in a top-levelDirectory.Packages.props(or similar) eliminates repetitive edits and ensures all server projects stay aligned.src/Besql/Demo/Bit.Besql.Demo.Client/Bit.Besql.Demo.Client.csproj (1)
13-13: Avoid per-file version specification
Move theMicrosoft.AspNetCore.Components.WebAssemblyversion to a shared property to simplify future upgrades and guarantee consistency.src/Bswup/FullDemo/Server/Bit.Bswup.Demo.Server.csproj (1)
11-11: Single-source package versions
For theMicrosoft.AspNetCore.Components.WebAssembly.Serverreference, prefer central package management to avoid manual propagation of version changes across projects.src/Websites/Careers/src/Bit.Websites.Careers.Client/Bit.Websites.Careers.Client.csproj (1)
99-101: Escaping the->operator is unnecessary but harmless; keep it consistent.
>inside an MSBuild attribute value does not require escaping, so@(IsolatedScssFiles->Replace(...))already parses correctly. Converting to->is acceptable but introduces visual noise and must be applied everywhere (many projects still have the unescaped form). Consider reverting or updating the rest of the repo for consistency.src/Websites/Sales/src/Bit.Websites.Sales.Server/Bit.Websites.Sales.Server.csproj (1)
14-17: Server project still references client WebAssembly packages – confirm necessity.If these packages are only transitively required via the linked client project, you can omit them from the server’s csproj to cut restore time and image size.
Otherwise, keep them but ensure they remain in sync (they are now 9.0.7 everywhere).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Knowledge Base: Disabled due to Reviews > Disable Knowledge Base setting
⛔ Files ignored due to path filters (9)
src/BlazorUI/Bit.BlazorUI.Extras/package-lock.jsonis excluded by!**/package-lock.jsonsrc/BlazorUI/Bit.BlazorUI/package-lock.jsonis excluded by!**/package-lock.jsonsrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Bswup/Bit.Bswup/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Butil/Bit.Butil/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Websites/Careers/src/Bit.Websites.Careers.Client/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Websites/Platform/src/Bit.Websites.Platform.Client/package-lock.jsonis excluded by!**/package-lock.jsonsrc/Websites/Sales/src/Bit.Websites.Sales.Client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (41)
src/Besql/Demo/Bit.Besql.Demo.Client/Bit.Besql.Demo.Client.csproj(1 hunks)src/Besql/Demo/Bit.Besql.Demo/Bit.Besql.Demo.csproj(2 hunks)src/Bit-CI.slnx(1 hunks)src/BlazorUI/Bit.BlazorUI.Extras/package.json(1 hunks)src/BlazorUI/Bit.BlazorUI/package.json(1 hunks)src/BlazorUI/Demo/Bit.BlazorUI.Demo.Server/Bit.BlazorUI.Demo.Server.csproj(1 hunks)src/BlazorUI/Demo/Bit.BlazorUI.Demo.Shared/Bit.BlazorUI.Demo.Shared.csproj(1 hunks)src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Bit.BlazorUI.Demo.Client.Core.csproj(1 hunks)src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/package.json(1 hunks)src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Windows/Bit.BlazorUI.Demo.Client.Windows.csproj(1 hunks)src/Bswup/Bit.Bswup.Demo/Bit.Bswup.Demo.csproj(1 hunks)src/Bswup/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo.Client/Bit.Bswup.NewDemo.Client.csproj(1 hunks)src/Bswup/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo.csproj(1 hunks)src/Bswup/Bit.Bswup/package.json(1 hunks)src/Bswup/FullDemo/Client/Bit.Bswup.Demo.Client.csproj(1 hunks)src/Bswup/FullDemo/Server/Bit.Bswup.Demo.Server.csproj(1 hunks)src/Butil/Bit.Butil/package.json(1 hunks)src/Butil/Demo/Bit.Butil.Demo.Maui/Bit.Butil.Demo.Maui.csproj(1 hunks)src/Butil/Demo/Bit.Butil.Demo.Web/Bit.Butil.Demo.Web.csproj(1 hunks)src/ResxTranslator/Bit.ResxTranslator/Bit.ResxTranslator.csproj(1 hunks)src/Templates/BlazorEmpty/Bit.BlazorEmpty/BlazorEmpty.Client/BlazorEmpty.Client.csproj(1 hunks)src/Templates/BlazorEmpty/Bit.BlazorEmpty/BlazorEmpty/BlazorEmpty.csproj(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/package.json(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Directory.Packages.props(5 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/.config/dotnet-tools.json(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Data/Migrations/20250702084958_Initial.Designer.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Data/Migrations/AppDbContextModelSnapshot.cs(1 hunks)src/Websites/Careers/src/Bit.Websites.Careers.Client/Bit.Websites.Careers.Client.csproj(3 hunks)src/Websites/Careers/src/Bit.Websites.Careers.Client/package.json(1 hunks)src/Websites/Careers/src/Bit.Websites.Careers.Server/Bit.Websites.Careers.Server.csproj(2 hunks)src/Websites/Careers/src/Bit.Websites.Careers.Shared/Bit.Websites.Careers.Shared.csproj(1 hunks)src/Websites/Platform/src/Bit.Websites.Platform.Client/Bit.Websites.Platform.Client.csproj(3 hunks)src/Websites/Platform/src/Bit.Websites.Platform.Client/Pages/Templates/Templates03GettingStartedPage.razor(1 hunks)src/Websites/Platform/src/Bit.Websites.Platform.Client/package.json(1 hunks)src/Websites/Platform/src/Bit.Websites.Platform.Server/Bit.Websites.Platform.Server.csproj(2 hunks)src/Websites/Platform/src/Bit.Websites.Platform.Shared/Bit.Websites.Platform.Shared.csproj(1 hunks)src/Websites/Sales/src/Bit.Websites.Sales.Client/Bit.Websites.Sales.Client.csproj(3 hunks)src/Websites/Sales/src/Bit.Websites.Sales.Client/package.json(1 hunks)src/Websites/Sales/src/Bit.Websites.Sales.Server/Bit.Websites.Sales.Server.csproj(2 hunks)src/Websites/Sales/src/Bit.Websites.Sales.Shared/Bit.Websites.Sales.Shared.csproj(1 hunks)src/global.json(1 hunks)
⏰ 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 and test
🔇 Additional comments (31)
src/Templates/BlazorEmpty/Bit.BlazorEmpty/BlazorEmpty/BlazorEmpty.csproj (1)
15-17: Package patch bump looks goodThe upgrade to
Microsoft.AspNetCore.Components.WebAssembly.Server9.0.7 for thenet9.0target aligns with the broader dependency sweep in this PR and keeps you on the latest security/bug-fix patch. I don’t see any compatibility foot-guns introduced by this single-line change.src/Butil/Demo/Bit.Butil.Demo.Maui/Bit.Butil.Demo.Maui.csproj (1)
52-56: All Microsoft.Extensions references are now on version 9.0.7
Confirmed via project-wide search—no remaining<PackageReference Include="Microsoft.Extensions.*"entries target 9.0.6. No further action required.src/Bswup/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo/Bit.Bswup.NewDemo.csproj (1)
11-11: AllMicrosoft.AspNetCore.Components.WebAssembly.Serverreferences are now on 9.0.7
Verified via ripgrep that there are no remaining 9.0.6 pins anywhere in the repo.
- The lone 8.0.15 entry lives in the BlazorEmpty template (targeting .NET 8) and isn’t part of the .NET 9 solution.
No further changes needed.src/ResxTranslator/Bit.ResxTranslator/Bit.ResxTranslator.csproj (1)
19-23: Patch bumps to 9.0.7 look goodAll
Microsoft.Extensions.*dependencies were moved from9.0.6→9.0.7. No API breaks are expected in a patch; 👍🏼.src/global.json (1)
3-3: .NET SDK roll-forward disabled – ensure environment matches version
No hard-coded references to9.0.301were found in the repo—good. Since"rollForward": "disable"enforces a strict match on9.0.302, please verify that:
- All CI/build agents and Docker images have .NET SDK 9.0.302 installed.
- Any external documentation or scripts (outside the repo) referencing
9.0.301are updated accordingly.src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/package.json (1)
3-3: Patch-levelesbuildbump looks good, just re-lock the workspace
0.25.5→0.25.6 is a bug-fix patch, so no breaking changes are expected. After merging, run a fresh install (pnpm install/npm ci) to refresh lockfiles and ensure CI picks up the new binary.src/Templates/BlazorEmpty/Bit.BlazorEmpty/BlazorEmpty.Client/BlazorEmpty.Client.csproj (1)
14-15: Dependency bump looks good – please double-check SDK alignmentThe 9.0.7 WebAssembly packages require the matching 9.0.302 SDK/runtime.
Make sure the build agents andglobal.json(already updated elsewhere) are in sync so CI restores don’t silently downgrade.src/Bit-CI.slnx (1)
131-133: New projects added – ensure they build & are wired into pipelines
Boilerplate.Server.AppHostandBoilerplate.Server.Sharedare now part of the solution.
Verify:
dotnet build Bit-CI.slnxsucceeds locally.- Any CI templates referencing explicit project lists include these two csproj files.
src/Butil/Demo/Bit.Butil.Demo.Web/Bit.Butil.Demo.Web.csproj (1)
10-12: Version bump acknowledged
Microsoft.AspNetCore.Components.WebAssembly*→ 9.0.7 matches the rest of the repo; no further action required.src/Bswup/Bit.Bswup.Demo/Bit.Bswup.Demo.csproj (1)
12-14: Consistent dependency upgradePackages upgraded to 9.0.7 – LGTM.
src/Bswup/FullDemo/Client/Bit.Bswup.Demo.Client.csproj (1)
13-15: Bump aligns with rest of solutionNo issues spotted with the move to 9.0.7.
src/Websites/Careers/src/Bit.Websites.Careers.Client/Bit.Websites.Careers.Client.csproj (1)
24-24: Dependency bumps look good – please run a full restore & smoke-test.Patch-level upgrades of the ASP.NET Core WebAssembly & Web packages are almost always binary-compatible, but occasionally ship with breaking SDK alignment requirements.
- Verify that
global.json(if present) pins an SDK ≥ 9.0.302 (the 9.0.7 servicing SDK).- Run
dotnet restore && dotnet build -c Releasein CI to surface any transitive-binding or analyzers issues.No further action if the build is green.
Also applies to: 46-46
src/Websites/Sales/src/Bit.Websites.Sales.Server/Bit.Websites.Sales.Server.csproj (1)
25-25: Swashbuckle upgrade to 9.0.3 acknowledged.No API-surface changes between 9.0.1 and 9.0.3; just ensure the generated OpenAPI doc still loads in Swagger UI.
src/Websites/Careers/src/Bit.Websites.Careers.Server/Bit.Websites.Careers.Server.csproj (1)
25-25: Swashbuckle 9.0.3 bump – LGTM.Run
/swaggerlocally once to confirm no runtime errors.src/Websites/Platform/src/Bit.Websites.Platform.Server/Bit.Websites.Platform.Server.csproj (1)
25-25: Swashbuckle upgrade looks fine.Nothing else to flag.
src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Bit.BlazorUI.Demo.Client.Core.csproj (1)
28-30: Patch updates applied – don’t forget to run demo app end-to-end.No breaking changes expected, but test the demo in both Debug & Release (esbuild minified) modes to catch any regressions introduced by the new runtime bits.
src/Websites/Sales/src/Bit.Websites.Sales.Client/Bit.Websites.Sales.Client.csproj (3)
24-24: Package version update looks good.The Microsoft.AspNetCore.Components.WebAssembly update from 9.0.6 to 9.0.7 is a legitimate patch release update.
46-46: Package version update looks good.The Microsoft.AspNetCore.Components.Web update from 9.0.6 to 9.0.7 is consistent with the other Microsoft package updates.
99-99: XML encoding fix is correct.The change from
>to>properly escapes the XML character in the MSBuild target's Outputs attribute.src/Templates/Boilerplate/Bit.Boilerplate/src/Directory.Packages.props (4)
16-16: Package version update looks good.The libphonenumber-csharp update to 9.0.9 is a legitimate version update.
108-108: Package version update looks good.The Swashbuckle.AspNetCore update to 9.0.3 is a legitimate version update for the OpenAPI/Swagger library.
116-116: Package version update looks good.The Twilio update to 7.11.5 is a legitimate version update.
18-21: Confirmed Microsoft Package Versions and No Known Security AdvisoriesAll Microsoft.AspNetCore.* packages have official 9.0.7 releases, and no public CVEs or security advisories exist for versions 9.0.6 or 9.0.7 according to current NuGet and security databases. Continue to monitor Microsoft’s security advisories for any future updates.
• Microsoft.AspNetCore.Authentication.JwtBearer – latest stable 9.0.7 (Jun 6, 2025)
• Microsoft.AspNetCore.Components.WebAssembly (and related Blazor packages) – latest stable 9.0.7 (Jun 6, 2025)
• No active CVEs or advisories for 9.0.x in Snyk, CVEDetails, or official Microsoft security bulletinssrc/Websites/Platform/src/Bit.Websites.Platform.Client/package.json (1)
3-3: Approve esbuild bump to 0.25.6 – no breaking changes
Verified that 0.25.6 is the latest stable release and introduces only non-breaking fixes (browser field regression, TS tuple label parsing, CSS prefixing). This devDependency update is safe to merge.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/.config/dotnet-tools.json (1)
6-6: Tool version update is consistent.The dotnet-ef tool update from 9.0.6 to 9.0.7 aligns with the Entity Framework Core package updates seen in the Directory.Packages.props file.
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Data/Migrations/20250702084958_Initial.Designer.cs (1)
21-21: ProductVersion bumped – confirm migration snapshot consistencyThe
ProductVersionannotation now targets EF Core 9.0.7, which matches the dependency upgrade across the solution.
Just make sure this file (and the correspondingAppDbContextModelSnapshot) were regenerated with the 9.0.7dotnet-eftool rather than edited manually, otherwise future diffs can get noisy.If you ran
dotnet ef migrations add/updateafter upgrading the packages, you're all set. 👍src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Data/Migrations/AppDbContextModelSnapshot.cs (1)
18-18: Patch version bump looks good
ProductVersionannotation updated to 9.0.7 to match the upgraded EF Core packages. No other snapshot changes are required.src/Websites/Platform/src/Bit.Websites.Platform.Client/Pages/Templates/Templates03GettingStartedPage.razor (1)
102-107: ✔ 9.0.302 SDK tarball is reachable
The download URLhttps://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.302/dotnet-sdk-9.0.302-linux-x64.tar.gzreturns HTTP/1.1 200 OK, so no further verification is needed.src/Websites/Platform/src/Bit.Websites.Platform.Client/Bit.Websites.Platform.Client.csproj (3)
27-28: Package patch upgrade acknowledged
Microsoft.AspNetCore.Components.WebAssemblybumped to 9.0.7 – consistent with server-side packages. No breaking changes are expected in a patch release.
49-50: Keep paired packages in sync
Microsoft.AspNetCore.Components.Webis also upgraded, maintaining parity with WebAssembly. ✔️
102-104: Good catch on XML escapingReplacing
>with>in theOutputsattribute prevents malformed XML on some MSBuild parsers.
closes #11089
Summary by CodeRabbit