tc-exceptions
Shared NuGet library defining the estate's exception hierarchy (TC.Exceptions) and a SQL-backed exception-log publisher with a Microsoft.Extensions.Logging provider (TC.Exceptions.Logging).
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | Microsoft.Extensions.Logging 10, Nerdbank.GitVersioning |
| Runtimes | .NET Framework 4.6.2, .NET 8, .NET 10 |
| Tests / CI | none / CI in place |
| Last commit | 2026-06-08 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | No signal No hosting signal in its pipelines (typical for libraries and contract packages) |
| Releases | 1 release pipeline(s): tc-exceptions |
| Integration | sqlserver |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Capability duplication
Part of the Exceptions packaging family (survivor): 71 dependents; recently multi-targeted, but its only test is an empty placeholder
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Ships as a package; ZDD applies to the services that consume it.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Not applicableLibraries ship as packages, not as running services. There is nothing to containerise.
Recommended actions
Put real tests around tc-exceptions
71 dependents and its only test is an empty placeholder. It already multi-targets; it needs a safety net before further change.
Impact: Highest leverage in the programme: releases consumers without touching them
proposedAssessment notes
tc-exceptions
Purpose
Publishes two NuGet packages consumed widely across the estate: TC.Exceptions (the ExceptionBase/TcException hierarchy with severity and type enums) and TC.Exceptions.Logging (an ExceptionLogPublisher singleton that writes exceptions to a SQL dbo.ExceptionLogInsert stored procedure, plus a Microsoft.Extensions.Logging provider wrapper).
Tech stack
Modern SDK-style solution (.slnx, Directory.Build.props, central package management). TC.Exceptions multi-targets net462/net8.0/net10.0; TC.Exceptions.Logging targets net462/net8.0. Uses Microsoft.Data.SqlClient 6.1, Microsoft.Extensions.Logging 10, Nerdbank.GitVersioning for semver, and a full analyser suite (SonarAnalyzer, SecurityCodeScan, NetAnalyzers).
Deployment
Included as prod_application with 1 release (tc-exceptions release pipeline from tc-exceptions CI build). YAML pipeline in-repo uses the shared InternalOSS/azure-pipelines-templates CI template with .NET 10 SDK, packing both packages to the internal Production NuGet feed.
Dependencies
Internal: TC.ConnectionBroker.Sql (tc-connectionbroker) — the logging package takes an ISqlConnectionBroker to resolve its connection string. No external services.
Data stores
No owned store or connection string; consumers inject a ConnectionBroker connection, and the library writes to whichever exception-log SQL Server database that resolves to (stored-procedure dbo.ExceptionLogInsert).
Integration points
None of its own beyond direct SQL Server writes for exception logs; it is a library, not a running service.
Code health
Actively maintained (last commit 2026-06-08) and recently modernised to .NET 10 with analysers enabled. However, the only test project contains a single empty placeholder test (UnitTest1.TestMethod1), and the README is untouched Azure DevOps boilerplate.
Modernisation risks
Low risk in itself — modern tooling and multi-targeting keep both legacy net462 and .NET 8/10 consumers working. The main concerns are estate-level: it is a high-fan-in dependency referenced by many services, so breaking changes ripple widely, and effectively zero test coverage means regressions in the exception-logging path would only surface downstream. The net462 target must survive until the last full-Framework consumer is retired.