Migrate .NET Framework to .NET 8

Migrate every .NET Framework 4.x service to .NET 8.

For each repository:
1. Convert project files:
   - Replace legacy `.csproj` format with SDK-style (`<Project Sdk="Microsoft.NET.Sdk">`)
   - Set `<TargetFramework>net8.0</TargetFramework>`
   - Remove `packages.config` and migrate package references into the `.csproj`
2. Replace System.Web with ASP.NET Core equivalents:
   - `HttpContext.Current` → injected `IHttpContextAccessor`
   - `System.Web.Http` controllers → `Microsoft.AspNetCore.Mvc` controllers
   - `Global.asax` → `Program.cs` with the minimal hosting model
3. Migrate configuration:
   - `Web.config` / `App.config` → `appsettings.json` + `IConfiguration`
   - `ConfigurationManager.AppSettings[...]` call sites → `IConfiguration` injection
4. Update logging from `log4net` / `System.Diagnostics.Trace` to `ILogger<T>`.
5. Update NuGet package versions for .NET 8 compatibility (`Newtonsoft.Json`,
   `EntityFramework` → `EntityFrameworkCore`, etc.).
6. Update CI runners to install the .NET 8 SDK.

The Problem

.NET Framework 4.x is Windows-only, on extended support, and architecturally incompatible with the modern .NET runtime. Every service still running on Framework carries a stack of legacy assumptions: `System.Web` HTTP pipeline, `Web.config` XML configuration, `Global.asax` lifecycle hooks, `HttpContext.Current` static access, and `packages.config` for NuGet. None of these survive the move to .NET 8 unchanged.

The migration isn't a flag flip; it's a project-file rewrite, an API replacement pass, and a configuration-model overhaul, repeated for every service. Teams routinely underestimate the long tail: WCF clients, `HttpModule`/`HttpHandler` plumbing, `System.Configuration` ambient state, and NuGet packages that never shipped a netstandard-compatible build. Each repo has its own legacy quirks, and a manual port that takes a week per service across 50 services is a year of engineering time the org doesn't have.

What Tidra Does

1. Converts legacy .csproj files to SDK-style with <TargetFramework>net8.0</TargetFramework> and migrates packages.config into <PackageReference> entries
2. Rewrites System.Web call sites to ASP.NET Core equivalents: HttpContext.Current to IHttpContextAccessor, System.Web.Http controllers to Microsoft.AspNetCore.Mvc, Global.asax to Program.cs minimal hosting
3. Migrates Web.config / App.config settings into appsettings.json and replaces ConfigurationManager.AppSettings[...] with injected IConfiguration
4. Replaces log4net / System.Diagnostics.Trace logging with ILogger<T> and the built-in logging abstractions
5. Bumps NuGet packages to .NET 8-compatible versions (e.g., EntityFramework to EntityFrameworkCore, Newtonsoft.Json current major)
6. Updates CI runners to install the .NET 8 SDK and adjusts build/test commands to dotnet build / dotnet test

Before & After

Customization Tips

• WCF services: Services exposing or consuming WCF endpoints need extra attention; WCF server isn't supported on .NET 8. Plan a CoreWCF replacement or REST/gRPC rewrite as a follow-up.
• Entity Framework: EF6 to EF Core is not a drop-in. Flag repositories using complex EF6 features (lazy loading proxies, custom conventions) for manual review before migration.
• Authentication: If you use System.Web Forms Authentication or Windows Auth, decide on the ASP.NET Core replacement (cookie auth, JWT, Negotiate) before running the migration.
• Hosting model: Services hosted in IIS via System.Web need a deployment-side change; Kestrel behind IIS, Azure App Service, or a container runtime are the typical replacements. Confirm the target host before bulk-migrating.