Files

26 KiB
Raw Permalink Blame History

.NET 10.0 Upgrade Plan — BettingPredictor

Table of Contents


1. Executive Summary

1.1 Scope & Target

Property Value
Solution BettingPredictor.sln
Projects 1 (BettingPredictor.csproj)
Project Type Classic WPF (non SDK-style)
Current Framework .NET Framework 4.8.1 (net481)
Target Framework .NET 10.0 (net10.0-windows)
Total LOC 7,140
Total Files 39 (27 with compatibility issues)
NuGet Packages 26 total — 9 to update, 6 to remove (framework-included)
Total Issues 2,202
Estimated LOC Impact 2,185+ (~30.6% of codebase)

1.2 Selected Strategy

All-At-Once Strategy — Single project upgraded in one atomic operation.

Rationale:

  • 1 project (well under 30-project threshold)
  • No inter-project dependencies
  • Homogeneous codebase (single WPF desktop application)
  • All 9 packages requiring update have known target versions (stable 10.0.5)
  • No incompatible packages — all have clear upgrade or removal paths
  • Fastest completion with single coordinated upgrade

1.3 Complexity Classification

Simple — ?5 projects, dependency depth 0, no security vulnerabilities, no circular dependencies.

Criterion Value Threshold
Project count 1 ? 5 ?
Dependency depth 0 ? 2 ?
Security vulnerabilities 0 None ?
High-risk items 0 None ?

Iteration strategy: Simple batch — all project details in 12 detail iterations.

1.4 Critical Issues

Priority Issue Impact Resolution
?? Mandatory SDK-style conversion Project won't build in .NET 10 without SDK-style format Use SDK-style conversion tool
?? Mandatory Target framework change net481 ? net10.0-windows Update TargetFramework in .csproj
?? High SqlClient namespace migration 1,264 source-incompatible API references across 16+ files Replace System.Data.SqlClient with Microsoft.Data.SqlClient
?? High 9 pre-release packages ? stable rc.1 packages must move to stable 10.0.5 Update PackageReference versions
?? Medium 6 framework-included packages Redundant packages may cause conflicts Remove PackageReference entries
?? Low WPF binary incompatibilities (897) Resolved automatically by recompilation against .NET 10.0 WPF No code changes — recompile with net10.0-windows
?? Low Behavioral changes (24) JsonDocument, System.Uri — may affect runtime behavior Requires runtime testing and validation
?? Low Legacy configuration (2) Settings.Designer.cs uses old config system Add System.Configuration.ConfigurationManager NuGet as bridge

2. Migration Strategy

2.1 Approach & Justification

All-At-Once — All updates performed as a single coordinated atomic operation with no intermediate states.

This is ideal because:

  • Single project: no dependency ordering needed
  • Clear package paths: all 9 packages have exact target versions (10.0.5 stable)
  • No incompatible packages: 0% incompatible, no blocking issues
  • WPF continuity: WPF is fully supported in .NET 10.0 with -windows TFM — same APIs, new runtime
  • Risk is contained: single project means build failures are immediately visible and fixable

2.2 Prerequisites

Before starting the atomic upgrade:

  1. Verify .NET 10.0 SDK installation

  2. Check global.json (if present)

    • Ensure it allows .NET 10.0 SDK or update/remove it
    • If present, update sdk.version to a .NET 10.0 compatible version
  3. Source control

    • Working branch: upgrade-to-NET8 (from main)
    • No pending changes

2.3 Implementation Timeline

Phase 0: Preparation

  • Verify .NET 10.0 SDK installation
  • Validate global.json compatibility

Phase 1: Atomic Upgrade

Operations (performed as single coordinated batch):

  1. Convert project to SDK-style format
  2. Update TargetFramework to net10.0-windows
  3. Update all 9 package references to stable versions
  4. Remove 6 framework-included package references
  5. Add Microsoft.Data.SqlClient package
  6. Replace all System.Data.SqlClient usages with Microsoft.Data.SqlClient
  7. Address legacy configuration bridge (add System.Configuration.ConfigurationManager if needed)
  8. Build solution and fix all compilation errors
  9. Verify: solution builds with 0 errors

Deliverable: Solution builds successfully targeting net10.0-windows

Phase 2: Validation

Operations:

  • No automated test projects exist in the solution
  • Manual verification of application startup and core functionality
  • Review behavioral changes (JsonDocument, System.Uri) at runtime

Deliverable: Application runs correctly on .NET 10.0


3. Detailed Dependency Analysis

This solution contains a single project with zero project dependencies and zero dependants. There is no dependency graph to navigate — the upgrade operates on one isolated project.

flowchart LR
    P1["BettingPredictor.csproj\nnet481 ? net10.0-windows"]
Property Value
Total projects 1
Dependency depth 0
Circular dependencies None
Critical path BettingPredictor.csproj (only project)
Migration phases needed 1 (atomic)
Test projects 0

Since there is only one project with no dependencies, the entire upgrade is executed as a single atomic operation. No phased ordering is required.


4. Project-by-Project Plans

4.1 BettingPredictor.csproj

Current State

Property Value
Path HorseRacingPredictor\HorseRacingPredictor\BettingPredictor.csproj
Target Framework net481 (.NET Framework 4.8.1)
SDK-style ? No (Classic WPF format)
Project Kind ClassicWpf
Lines of Code 7,140
Files 43 total, 27 with incidents
NuGet Packages 26 (9 update, 6 remove, 11 compatible)
Dependencies 0 project references
Dependants 0
Risk Level ?? Medium

Key technologies used:

  • WPF (Windows Presentation Foundation) — primary UI framework
  • WebView2 — embedded browser control
  • Microsoft.ML / ML.NET — machine learning predictions
  • System.Data.SqlClient — SQL database access
  • RestSharp — REST API client
  • CsvHelper — CSV file handling
  • Newtonsoft.Json & System.Text.Json — JSON serialization

Target State

Property Value
Target Framework net10.0-windows
SDK-style ? Yes
Updated packages 9
Removed packages 6 (framework-included)
New packages Microsoft.Data.SqlClient, System.Configuration.ConfigurationManager

Migration Steps

Step 1: Convert to SDK-style project

  • Use the SDK-style conversion tool on BettingPredictor.csproj
  • The conversion tool handles:
    • Migrating <PackageReference> entries from packages.config
    • Setting up the new SDK-style project structure
    • Preserving existing project configuration
  • After conversion, the .csproj will use Microsoft.NET.Sdk format

Step 2: Update TargetFramework

  • Change <TargetFramework> to net10.0-windows
  • This enables WPF and WinForms support via the -windows platform specifier
  • No need for <UseWPF>true</UseWPF> separately — SDK-style WPF projects include this automatically when converted

Step 3: Update package references (9 packages)

  • Update all pre-release (rc.1) packages to stable 10.0.5 versions
  • See §5.1 Packages to Update for complete version matrix

Step 4: Remove framework-included packages (6 packages)

  • Remove references to packages whose functionality is now built into .NET 10.0
  • See §5.2 Packages to Remove for complete list

Step 5: Migrate SqlClient

  • Add Microsoft.Data.SqlClient NuGet package
  • In all affected files, replace:
    • using System.Data.SqlClient; ? using Microsoft.Data.SqlClient;
  • The API surface is identical — SqlConnection, SqlCommand, SqlParameter, SqlTransaction all exist in Microsoft.Data.SqlClient with the same signatures
  • Affected files (16 files, ~1,264 API references):
    • Manager\Database.cs (12 issues) — base database class with GetConnection(), transactions
    • Football\Manager\Database.cs (10 issues) — football-specific DB operations
    • Football\Database\APIResponse.cs (82 issues)
    • Football\Database\LeagueStats.cs (76 issues)
    • Football\Database\Fixture.cs (67 issues)
    • Football\Database\Comparison.cs (64 issues)
    • Football\Database\League.cs (57 issues)
    • Football\Database\TeamStats.cs (56 issues)
    • Football\Database\Prediction.cs (52 issues)
    • Football\Database\Odds.cs (43 issues)
    • Football\Database\Score.cs (40 issues)
    • Football\Database\FixtureLeague.cs (39 issues)
    • Football\Database\H2H.cs (20 issues)
    • Football\Database\Goals.cs (16 issues)
    • Football\Database\BetType.cs (12 issues)
    • Football\Database\Bookmaker.cs (12 issues)

Step 6: Address legacy configuration

  • Properties\Settings.Designer.cs (2 issues) uses the legacy System.Configuration APIs
  • Add NuGet package System.Configuration.ConfigurationManager as an interim bridge
  • This provides the ConfigurationManager, Settings, and related classes on .NET 10.0
  • ?? Long-term recommendation: migrate to Microsoft.Extensions.Configuration with appsettings.json

Step 7: Restore, build, and fix compilation errors

  • Run dotnet restore to resolve all updated package references
  • Build the entire solution
  • Fix any compilation errors discovered (expected areas: SqlClient namespace, removed APIs, configuration)
  • Rebuild and verify: 0 compilation errors

Validation Checklist

  • Project converted to SDK-style
  • TargetFramework set to net10.0-windows
  • All 9 packages updated to stable versions
  • 6 framework-included packages removed
  • Microsoft.Data.SqlClient added and all usages migrated
  • System.Configuration.ConfigurationManager added (if needed)
  • Solution builds with 0 errors
  • Solution builds with 0 warnings (best effort)
  • Application starts and main UI renders correctly

5. Package Update Reference

5.1 Packages to Update

All 9 packages are currently on pre-release 10.0.0-rc.1.25451.107 and must be updated to stable 10.0.5.

Package Current Version Target Version Reason
Microsoft.Bcl.AsyncInterfaces 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
Microsoft.Bcl.Numerics 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.CodeDom 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.Collections.Immutable 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.IO.Pipelines 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.Numerics.Tensors 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.Text.Encodings.Web 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.Text.Json 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable
System.Threading.Channels 10.0.0-rc.1.25451.107 10.0.5 Pre-release ? stable

5.2 Packages to Remove (Framework-Included)

These packages provide functionality that is now built into the .NET 10.0 runtime. Their PackageReference entries should be removed to avoid version conflicts.

Package Current Version Reason for Removal
System.Buffers 4.6.1 Included in .NET 10.0 runtime
System.Memory 4.6.3 Included in .NET 10.0 runtime
System.Numerics.Vectors 4.6.1 Included in .NET 10.0 runtime
System.Reflection.Emit.Lightweight 4.7.0 Included in .NET 10.0 runtime
System.Threading.Tasks.Extensions 4.6.3 Included in .NET 10.0 runtime
System.ValueTuple 4.6.1 Included in .NET 10.0 runtime

5.3 Packages to Add

Package Version Reason
Microsoft.Data.SqlClient Latest stable Replaces System.Data.SqlClient for .NET 10.0
System.Configuration.ConfigurationManager Latest stable for net10.0 Bridge for legacy Settings.Designer.cs configuration

5.4 Compatible Packages (No Change)

These packages are already compatible with .NET 10.0 and require no version changes.

Package Current Version Notes
CsvHelper 33.1.0 ? Compatible
Microsoft.Bcl.HashCode 6.0.0 ? Compatible
Microsoft.CSharp 4.7.0 ? Compatible
Microsoft.ML 5.0.0-preview.25503.2 ? Compatible (pre-release but no stable alternative)
Microsoft.ML.CpuMath 5.0.0-preview.25503.2 ? Compatible
Microsoft.ML.DataView 5.0.0-preview.25503.2 ? Compatible
Microsoft.ML.FastTree 5.0.0-preview.25503.2 ? Compatible
Microsoft.Web.WebView2 1.0.3800.47 ? Compatible
Newtonsoft.Json 13.0.4 ? Compatible
RestSharp 112.1.1-alpha.0.4 ? Compatible
System.Runtime.CompilerServices.Unsafe 6.1.2 ? Compatible

6. Breaking Changes Catalog

6.1 SqlClient Namespace Migration

Category: Source Incompatible Impact: 1,264 API references across 16+ files Severity: High — requires code changes in every database access file

Problem: System.Data.SqlClient is not available as a built-in namespace in .NET 10.0. The legacy System.Data.SqlClient namespace shipped with .NET Framework is replaced by the standalone Microsoft.Data.SqlClient package.

Resolution:

  1. Add NuGet package Microsoft.Data.SqlClient
  2. In every file that uses System.Data.SqlClient, change:
    // Before
    using System.Data.SqlClient;
    
    // After
    using Microsoft.Data.SqlClient;
    
  3. The API surface is API-compatible — same class names (SqlConnection, SqlCommand, SqlParameter, SqlTransaction, etc.) with identical method signatures
  4. No logic changes required — only the using directive changes

Affected classes and methods (most frequent):

  • SqlParameterCollection / SqlCommand.Parameters (273 references)
  • SqlParameter (273 references)
  • SqlParameterCollection.AddWithValue() (270 references)
  • SqlConnection (35 references)
  • SqlCommand (33 references)
  • SqlCommand.ExecuteNonQuery() (23 references)
  • SqlCommand.ExecuteScalar() (8 references)
  • SqlTransaction / BeginTransaction() / Commit() / Rollback() (10 references)

6.2 WPF Binary Incompatibilities

Category: Binary Incompatible Impact: 897 API references Severity: Low — resolved automatically by recompilation

Problem: WPF types in .NET 10.0 are binary-incompatible with .NET Framework 4.8.1 assemblies. The types exist at the same namespaces and with the same API surfaces, but are in different assemblies.

Resolution: No code changes needed. Targeting net10.0-windows and recompiling resolves all 897 binary incompatibilities. The WPF APIs (TextBox, TextBlock, Button, ComboBox, DataGrid, DatePicker, CheckBox, RadioButton, ProgressBar, MessageBox, Grid, Visibility, etc.) are fully available in .NET 10.0 WPF.

6.3 Windows Forms API References

Category: Binary Incompatible Impact: 18 API references Severity: Low — resolved automatically by targeting net10.0-windows

Problem: The project uses some Windows Forms APIs (likely FolderBrowserDialog, OpenFileDialog, or similar interop). These are binary incompatible across frameworks.

Resolution: The -windows platform specifier in net10.0-windows automatically enables both WPF and WinForms support. Recompilation resolves these references.

6.4 Legacy Configuration System

Category: Source Incompatible Impact: 2 API references in Properties\Settings.Designer.cs Severity: Low

Problem: The legacy System.Configuration APIs (ConfigurationManager, ApplicationSettingsBase, etc.) from app.config / web.config are not built into .NET 10.0.

Resolution:

  • Add NuGet package System.Configuration.ConfigurationManager to provide the legacy APIs as a bridge
  • Properties\Settings.Designer.cs will compile and work as before
  • ?? Long-term recommendation: Migrate to Microsoft.Extensions.Configuration with JSON-based configuration (appsettings.json), but this is optional and can be deferred

6.5 Behavioral Changes

Category: Behavioral Change Impact: 24 API references (16 JsonDocument, 6 System.Uri, 2 other) Severity: Low — no compilation errors, but may cause runtime behavior differences

6.5.1 System.Text.Json.JsonDocument (16 references)

Files affected: HorseRacing\API\RacingApiClient.cs, HorseRacing\Main.cs

Potential changes in .NET 10.0:

  • Stricter JSON parsing by default
  • Changes to how trailing commas, comments, and edge cases are handled
  • JsonSerializerOptions defaults may differ

Mitigation: Test JSON parsing scenarios thoroughly. If issues arise, configure JsonSerializerOptions or JsonDocumentOptions to match previous behavior (e.g., AllowTrailingCommas = true).

6.5.2 System.Uri (6 references)

Files affected: HorseRacing\API\RacingApiClient.cs, HorseRacing\Main.cs

Potential changes in .NET 10.0:

  • More strict URI parsing conforming to RFC 3986
  • Changes in how relative URIs and encoding edge cases are handled

Mitigation: Test URI-based operations (API endpoint construction, WebView2 navigation). Typically no issues with standard HTTP/HTTPS URIs.


7. Testing & Validation Strategy

7.1 Automated Tests

?? No automated test projects exist in this solution. There are no unit test, integration test, or other test projects to execute.

7.2 Build Verification

The primary automated validation is build success:

  • dotnet restore completes without errors
  • dotnet build completes with 0 errors
  • No NuGet package version conflicts
  • No unresolved assembly references

7.3 Runtime Validation Areas

Since there are no automated tests, the following areas should be manually verified after the upgrade:

Area What to Verify Risk
Application startup App starts, main window renders correctly Low — WPF is fully supported
Navigation All 4 pages (Football, Racing, Virtual Football, Settings) load Low
WebView2 Virtual Football page loads WebView2 browser correctly Low — WebView2 is compatible
Database operations Football/Racing data download and storage work (SqlClient migration) Medium — namespace change
API calls FormFav and Football API calls succeed (RestSharp + JSON parsing) Medium — behavioral changes
CSV import/export CsvHelper operations work correctly Low — compatible package
Settings persistence Save/load settings works (legacy config bridge) Low
ML predictions ML.NET prediction pipeline runs without errors Low — compatible packages

7.4 Behavioral Change Validation

These specific scenarios require targeted testing due to behavioral changes in .NET 10.0:

  1. JsonDocument parsing — Test API response parsing in RacingApiClient.cs and Main.cs:

    • Verify JSON responses from FormFav API are parsed correctly
    • Test edge cases: empty responses, malformed JSON, large payloads
  2. System.Uri — Test URL construction in API clients:

    • Verify API endpoint URLs are constructed correctly
    • Test WebView2 navigation URLs

8. Risk Management

8.1 Risk Assessment

Risk Level Description Mitigation
SDK-style conversion fails ?? Medium Conversion tool may not handle all classic WPF project features Manual .csproj cleanup after conversion; verify all files included
SqlClient migration breaks DB access ?? Medium Namespace-only change, but large surface area (1,264 references) Global find-and-replace System.Data.SqlClient ? Microsoft.Data.SqlClient; API is compatible
ML.NET packages incompatible ?? Low ML packages are pre-release (5.0.0-preview) Assessment confirms compatibility; fall back to stable ML.NET 4.x if needed
RestSharp pre-release issues ?? Low RestSharp is 112.1.1-alpha.0.4 Assessment confirms compatibility; fall back to stable RestSharp if needed
Behavioral changes cause runtime issues ?? Low JsonDocument and Uri behavior differences Configure strict/lenient options; manual testing of affected paths
Legacy config bridge insufficient ?? Low Settings.Designer.cs may need additional adjustments System.Configuration.ConfigurationManager package provides full bridge
WPF rendering differences ?? Low Minor visual differences between .NET Framework and .NET 10.0 WPF Visual inspection; typically identical rendering

8.2 Contingency Plans

Scenario Action
SDK-style conversion produces broken .csproj Manually create SDK-style .csproj with correct structure, copy settings
Microsoft.Data.SqlClient has API differences Check Microsoft.Data.SqlClient migration guide for any breaking changes beyond namespace
ML.NET predictions fail Pin ML.NET to last known working version for net10.0
Build fails with unresolvable errors Roll back to main branch, investigate specific errors

9. Complexity & Effort Assessment

9.1 Overall Assessment

Factor Rating Justification
Overall complexity ?? Medium Single project but large LOC impact (30.6%), major SqlClient migration
SDK-style conversion Low Automated tool handles conversion
Framework update Low Single TFM change
Package updates Low All 9 are simple version bumps (rc ? stable)
Package removals Low 6 straightforward removals
SqlClient migration Medium Large number of files (16+) but mechanical namespace change
WPF compatibility Low Resolved by recompilation
Configuration bridge Low Single package addition, 2 affected references
Behavioral changes Low 24 references, requires testing not code changes

9.2 Complexity by File Area

Area Files Affected Issue Count Complexity
Football Database classes 14 files ~1,200+ Medium (bulk SqlClient rename)
Manager Database classes 2 files 22 Low
API Client / Main 2 files 7 Low (behavioral testing)
Settings 1 file 2 Low
Project file 1 file 17 Low (tooling-assisted)
WPF UI files ~8 files 897 Low (automatic via recompilation)

10. Source Control Strategy

10.1 Branch Strategy

Property Value
Source branch main
Upgrade branch upgrade-to-NET8
Approach Single commit for entire atomic upgrade

10.2 Commit Strategy

Single commit for the entire All-At-Once upgrade operation:

  • Commit message: Upgrade BettingPredictor from .NET Framework 4.8.1 to .NET 10.0
  • Contents: SDK-style conversion + TFM change + all package updates + SqlClient migration + config bridge + compilation fixes
  • Rationale: Single project, single atomic operation — one commit captures the complete upgrade

10.3 Review & Merge

  • Create Pull Request from upgrade-to-NET8 ? main
  • PR checklist:
    • Solution builds with 0 errors
    • All package references correct (no pre-release, no framework-included)
    • SqlClient migration complete (no remaining System.Data.SqlClient references)
    • Application starts and core functionality works
    • Manual verification of behavioral change areas

11. Success Criteria

11.1 Technical Criteria

  • Project targets net10.0-windows
  • Project uses SDK-style format
  • All 9 packages updated from rc.1 to stable 10.0.5
  • All 6 framework-included packages removed
  • Microsoft.Data.SqlClient added and all System.Data.SqlClient references migrated
  • System.Configuration.ConfigurationManager added for legacy config bridge
  • Solution builds with 0 errors
  • No NuGet package dependency conflicts
  • No security vulnerabilities

11.2 Quality Criteria

  • No remaining references to System.Data.SqlClient namespace
  • No remaining pre-release package versions (except ML.NET and RestSharp which are already pre-release by design)
  • No framework-included packages remaining as explicit references
  • Code quality maintained (no workarounds or hacks)

11.3 Process Criteria

  • All-At-Once strategy followed (single atomic operation)
  • All changes in upgrade-to-NET8 branch
  • Single commit capturing complete upgrade
  • Assessment findings fully addressed