[Backend][Cleanup] Dependency audit — unused NuGet references across projects inflate every service image (ExCSS, Ical.Net, Redis.OM, Newtonsoft.Json, Configuration.* and more) #578

New Issue

2026-07-14T17:20:22Z

spikerj commented

2026-07-14 17:20:22 +00:00

QA Team — filed 2026-07-14 from the README audit, at spikerj's direction (decision: ticket a dependency audit).

The audit read every csproj and cross-checked each PackageReference against actual source usage. Confirmed-unused references found so far:

Project	Unused reference	Note
`SpikerSoft.Business`	ExCSS 4.3.1	no source file uses it
`SpikerSoft.Business`	Ical.Net 5.2.3	no source file uses it (the API has its own reference for calendar feeds)
`SpikerSoft.Business`	Redis.OM 1.3.0	no source file uses it
`SpikerSoft.Business`	Newtonsoft.Json 13.0.4	used ONLY for `[JsonProperty]` attributes on five legacy models (Book, Chapter, GoogleBookResponse, Paste, User) — replaceable with `System.Text.Json` attributes, dropping the dependency entirely
`SpikerSoft.Common`	Microsoft.Extensions.Configuration + .Configuration.Json	zero `IConfiguration` usage in the project
`SpikerSoft.AI.MCPServer`	MongoDB.EntityFrameworkCore, NRedisStack	unused (also in #563's cleanup list)
`SpikerSoft.Contracts.Workers`	Microsoft.Extensions.Logging.Abstractions	sole package ref; no `ILogger` usage anywhere in the project

Why it's worth doing: SpikerSoft.Business and SpikerSoft.Common are referenced by nearly every deployable, so their unused packages are restored, compiled, and shipped in every service image on the swarm — including the arm64 images on the Jetson nodes where image pull time already hurts (#562).

Ask: remove the unused references (the build is the proof), and consider adding a periodic dependency check so drift doesn't re-accumulate. Also worth a look while in there: Microsoft.AspNetCore.SignalR 1.2.11 (an ASP.NET Core 2.x-era package) sits alongside the 10.0.9 components — confirm it's intentional or drop it.

Related: #563 (MCPServer cleanup), #576 (legacy manager classes).

**QA Team** — filed 2026-07-14 from the README audit, at spikerj's direction (decision: ticket a dependency audit). The audit read every csproj and cross-checked each `PackageReference` against actual source usage. Confirmed-unused references found so far: | Project | Unused reference | Note | |---|---|---| | `SpikerSoft.Business` | **ExCSS 4.3.1** | no source file uses it | | `SpikerSoft.Business` | **Ical.Net 5.2.3** | no source file uses it (the API has its own reference for calendar feeds) | | `SpikerSoft.Business` | **Redis.OM 1.3.0** | no source file uses it | | `SpikerSoft.Business` | **Newtonsoft.Json 13.0.4** | used ONLY for `[JsonProperty]` attributes on five legacy models (Book, Chapter, GoogleBookResponse, Paste, User) — replaceable with `System.Text.Json` attributes, dropping the dependency entirely | | `SpikerSoft.Common` | **Microsoft.Extensions.Configuration** + **.Configuration.Json** | zero `IConfiguration` usage in the project | | `SpikerSoft.AI.MCPServer` | **MongoDB.EntityFrameworkCore**, **NRedisStack** | unused (also in #563's cleanup list) | | `SpikerSoft.Contracts.Workers` | **Microsoft.Extensions.Logging.Abstractions** | sole package ref; no `ILogger` usage anywhere in the project | **Why it's worth doing:** `SpikerSoft.Business` and `SpikerSoft.Common` are referenced by nearly every deployable, so their unused packages are restored, compiled, and **shipped in every service image on the swarm** — including the arm64 images on the Jetson nodes where image pull time already hurts (#562). **Ask:** remove the unused references (the build is the proof), and consider adding a periodic dependency check so drift doesn't re-accumulate. Also worth a look while in there: `Microsoft.AspNetCore.SignalR 1.2.11` (an ASP.NET Core 2.x-era package) sits alongside the 10.0.9 components — confirm it's intentional or drop it. **Related:** #563 (MCPServer cleanup), #576 (legacy manager classes).

spikerj commented

2026-07-22 03:53:33 +00:00

Board-sweep note (2026-07-22): no dependency-removal work has landed (ExCSS still referenced in Business/Data/EventHandlers.Infrastructure, Redis.OM still in Api — verified in current master csprojs). One correction to the audit list: Ical.Net is no longer unused — the unified-scheduling epic #781 recurrence engine (RecurrenceExpansionService, merged) is built on it. Drop it from the retire list before anyone sweeps. Ticket stays open.

Board-sweep note (2026-07-22): no dependency-removal work has landed (`ExCSS` still referenced in Business/Data/EventHandlers.Infrastructure, `Redis.OM` still in Api — verified in current master csprojs). One correction to the audit list: **`Ical.Net` is no longer unused** — the unified-scheduling epic #781 recurrence engine (`RecurrenceExpansionService`, merged) is built on it. Drop it from the retire list before anyone sweeps. Ticket stays open.

spikerj commented

2026-07-29 17:04:30 +00:00

Audited against origin/master — PARTIAL (1 of 8 rows resolved), and ⚠️ one row in this ticket is factually wrong and would break production if acted on.

Strike the Ical.Net row before anyone works this

SpikerSoft.Business/SpikerSoft.Business.csproj:60 Ical.Net is not unused. It is the engine behind #781's recurrence work:

SpikerSoft.Business/Domain/Calendar/Services/RecurrenceExpansionService.cs — RRULE expansion
SpikerSoft.Business.Scheduling/Calendar/IcsImportParser.cs — the Phase 3 .ics import
SpikerSoft.Api/Extensions/ServiceCollectionExtensions.cs

Removing it would break calendar recurrence and iCal import outright. The ticket was filed 2026-07-14; #781's Phase 1 landed 2026-07-22 and turned a genuinely-unused reference into a load-bearing one. Worth updating the body so this doesn't get actioned from the list.

That's a general hazard with dependency-audit tickets: "unused" is a point-in-time observation with a short shelf life, and this list is 15 days old.

Still present (file-verified)

SpikerSoft.Business.csproj:55 ExCSS, :80 Redis.OM, :75 Newtonsoft.Json — no .cs under SpikerSoft.Business/ references any of them.
SpikerSoft.Common.csproj:11 Microsoft.Extensions.Configuration, :12 .Configuration.Json.
MCPServer's MongoDB.EntityFrameworkCore + NRedisStack (also #563 item 5).
Directory.Packages.props:49 still pins Microsoft.AspNetCore.SignalR 1.2.11.

Resolved

SpikerSoft.Contracts.Workers.csproj now carries only MediatR (:19) — Microsoft.Extensions.Logging.Abstractions is gone. Whether that was deliberate for this ticket or incidental drift isn't determinable.

Caveat on the remaining "unused" verdicts

These confirm no references within SpikerSoft.Business/**/*.cs. They do not rule out a transitive consumer relying on a package flowing through Business's reference graph — as the ticket itself says, the build is the real proof. Given the Ical.Net case, I'd treat every row as needing re-verification at removal time rather than trusting the original list.

Remaining: correct the Ical.Net row, then work the six genuinely-still-present rows with a build after each.

Audited against `origin/master` — **PARTIAL (1 of 8 rows resolved), and ⚠️ one row in this ticket is factually wrong and would break production if acted on.** ## Strike the Ical.Net row before anyone works this `SpikerSoft.Business/SpikerSoft.Business.csproj:60` `Ical.Net` is **not unused**. It is the engine behind #781's recurrence work: - `SpikerSoft.Business/Domain/Calendar/Services/RecurrenceExpansionService.cs` — RRULE expansion - `SpikerSoft.Business.Scheduling/Calendar/IcsImportParser.cs` — the Phase 3 `.ics` import - `SpikerSoft.Api/Extensions/ServiceCollectionExtensions.cs` Removing it would break calendar recurrence and iCal import outright. The ticket was filed 2026-07-14; #781's Phase 1 landed 2026-07-22 and turned a genuinely-unused reference into a load-bearing one. Worth updating the body so this doesn't get actioned from the list. That's a general hazard with dependency-audit tickets: "unused" is a point-in-time observation with a short shelf life, and this list is 15 days old. ## Still present (file-verified) - `SpikerSoft.Business.csproj:55` `ExCSS`, `:80` `Redis.OM`, `:75` `Newtonsoft.Json` — no `.cs` under `SpikerSoft.Business/` references any of them. - `SpikerSoft.Common.csproj:11` `Microsoft.Extensions.Configuration`, `:12` `.Configuration.Json`. - MCPServer's `MongoDB.EntityFrameworkCore` + `NRedisStack` (also #563 item 5). - `Directory.Packages.props:49` still pins `Microsoft.AspNetCore.SignalR` 1.2.11. ## Resolved `SpikerSoft.Contracts.Workers.csproj` now carries only `MediatR` (`:19`) — `Microsoft.Extensions.Logging.Abstractions` is gone. Whether that was deliberate for this ticket or incidental drift isn't determinable. ## Caveat on the remaining "unused" verdicts These confirm no references *within* `SpikerSoft.Business/**/*.cs`. They do not rule out a transitive consumer relying on a package flowing through Business's reference graph — as the ticket itself says, the build is the real proof. Given the Ical.Net case, I'd treat every row as needing re-verification at removal time rather than trusting the original list. **Remaining:** correct the Ical.Net row, then work the six genuinely-still-present rows with a build after each.

spikerj referenced this issue

2026-07-29 17:05:19 +00:00

[Backend][MCPServer] Pre-deployment cleanup for SpikerSoft.AI.MCPServer — demo leftovers, unregistered prompts, no observability wiring, no stack/CI #563

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#578