Skip to content

Instantly share code, notes, and snippets.

@spboyer

spboyer/dotnet-sdk-workload-corruption-report.md

Created August 6, 2025 13:59
Show Gist options
  • Save spboyer/f06fa6f800e506cac1069b684ac100da to your computer and use it in GitHub Desktop.
Save spboyer/f06fa6f800e506cac1069b684ac100da to your computer and use it in GitHub Desktop.
Download ZIP
.NET SDK Workload Corruption Technical Report - Complete analysis of .NET 9.0.303 SDK workload corruption affecting .NET Aspire 9.4.0 development, including detailed recovery process and comprehensive recommendations for the .NET team.
Raw
dotnet-sdk-workload-corruption-report.md

.NET SDK Workload Corruption and .NET Aspire Issues Report

Executive Summary

This document details a complete .NET SDK workload corruption that prevented any .NET development, the attempted resolution strategies, and the eventual recovery process. The issue initially manifested during .NET Aspire development but affected the entire .NET SDK installation.

Environment Details

System Configuration

  • OS: Windows 11 (Build 10.0.26200)
  • PowerShell: 7.5.2 (Core Edition)
  • Architecture: x64 (Windows)
  • RID: win-x64
  • Initial .NET SDK: Multiple versions with corrupted workloads
  • Final Working SDK: .NET 9.0.303
  • SDK Commit: 5d97611193
  • Workload Version: 9.0.300-manifests.407ced12
  • MSBuild Version: 17.14.13+65391c53b
  • Runtime Host Version: 9.0.7
  • Project Type: .NET Aspire 9.4.0 microservices application
  • Date Range: August 5-6, 2025

Current .NET Installation Details

.NET SDK:
 Version:           9.0.303
 Commit:            5d97611193
 Workload version:  9.0.300-manifests.407ced12
 MSBuild version:   17.14.13+65391c53b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26200
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.303\

Complete .NET SDK Inventory

.NET SDKs installed:
  8.0.117 [C:\Program Files\dotnet\sdk]
  8.0.300-preview.24203.14 [C:\Program Files\dotnet\sdk]
  8.0.300 [C:\Program Files\dotnet\sdk]
  8.0.314 [C:\Program Files\dotnet\sdk]
  8.0.411 [C:\Program Files\dotnet\sdk]
  9.0.303 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.32, 6.0.27, 7.0.16, 7.0.20, 8.0.2, 8.0.5, 8.0.17, 9.0.7
  Microsoft.NETCore.App 3.1.32, 6.0.27, 7.0.16, 7.0.20, 8.0.2, 8.0.5, 8.0.17, 9.0.7
  Microsoft.WindowsDesktop.App 3.1.32, 6.0.27, 7.0.16, 7.0.20, 8.0.2, 8.0.5, 8.0.17, 9.0.7

Architecture Dependencies

  • x86 Runtime: Additional x86 dotnet installation detected at C:\Program Files (x86)\dotnet
  • Registry Entry: [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Initial Problem: Complete .NET SDK Corruption

Symptoms

The .NET SDK workload system was completely corrupted, manifesting as:

# ANY dotnet command failed with workload conflicts:
error NETSDK1147: To build this project, the following workloads must be installed: 
microsoft.net.workload.mono.toolchain.current
error: Workload installation failed. Please see x:\temp\... for details.

# Specific version conflict:
Microsoft.NET.Workload.Emscripten.Current (version 9.0.7) 
vs 
microsoft.net.workload.mono.toolchain.current (requiring version 9.0.8)

Impact Scope

❌ EVERYTHING was broken:

  • .NET Aspire projects (original target)
  • Basic ASP.NET Core projects
  • Console applications
  • dotnet new templates
  • dotnet build on any project
  • dotnet restore operations
  • Even dotnet --version sometimes failed

Root Cause Analysis

The corruption appeared to stem from:

  1. Conflicting workload manifests in %PROGRAMFILES%\dotnet\sdk-manifests
  2. Version mismatches between different workload components
  3. Incomplete workload installations that left the SDK in an inconsistent state
  4. Registry corruption affecting workload discovery

Attempted Resolution Strategies

Strategy 1: Standard Workload Cleanup ❌

dotnet workload clean
dotnet workload clean --all

Result: Failed - Core manifests remained corrupted, system recreated problematic files

Strategy 2: Manual Manifest Deletion ❌

# Manually deleted problematic folders:
C:\Program Files\dotnet\sdk-manifests\9.0.100\Microsoft.NET.Workload.Emscripten.Current
C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current

Result: Failed - System automatically recreated corrupted manifests on next operation

Strategy 3: Workload Update/Repair ❌

dotnet workload update
dotnet workload restore

Result: Failed - Workload system too corrupted to perform updates

Strategy 4: Selective Project Modification ❌

  • Temporarily removed Aspire references
  • Simplified project files to basic ASP.NET Core
  • Removed all workload-dependent packages Result: Failed - Corruption was at SDK level, not project level

Strategy 5: Nuclear Option - Complete .NET Reinstall ✅

1. Complete .NET Uninstallation:

# Via Windows Settings > Apps & Features
# Uninstalled ALL .NET installations:
# - .NET 9.0 Runtime
# - .NET 8.0 Runtime  
# - .NET 7.0 Runtime
# - .NET Desktop Runtime (all versions)
# - Microsoft .NET SDK (all versions)

2. Manual Cleanup Phase:

# Removed residual installation directories
Remove-Item "C:\Program Files\dotnet\" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Program Files (x86)\dotnet\" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:USERPROFILE\.dotnet\" -Recurse -Force -ErrorAction SilentlyContinue

# Registry cleanup (handled by fresh installation)
# HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\

3. Fresh Installation Verification:

# Downloaded .NET 9.0.303 from official Microsoft site
# Installed via dotnet-sdk-9.0.303-win-x64.exe
# Verified clean installation
PS> dotnet --version
9.0.303

PS> dotnet workload list
No workloads installed.

PS> dotnet new console --dry-run
The template "Console App" was created successfully.

4. Selective Workload Installation:

PS> dotnet workload install aspire
Installing package 'Aspire.Hosting.Sdk' version '8.2.2'.
Installing package 'Aspire.ProjectTemplates' version '8.2.2'.  # Note: Still 8.2.2!
Installing package 'Microsoft.Maui.Graphics.Msi' version '9.0.82'.
Installing package 'Microsoft.Maui.Core.Msi' version '9.0.82'.
Installing package 'Microsoft.Maui.Controls.Msi' version '9.0.82'.
Installing package 'Microsoft.Maui.Essentials.Msi' version '9.0.82'.
Successfully installed workload(s) aspire.

5. Application Build Verification:

# .NET Aspire 9.4.0 AppHost project now builds successfully
PS> cd C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost
PS> dotnet build
Build succeeded.
    0 Warning(s)
    0 Error(s)

# Blazor application builds and runs
PS> cd ..\PetReservations.Web
PS> dotnet run
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:5001

Workload System Analysis

Current Working Workload Configuration

Installed Workloads (Post-Recovery):

[android]
   Installation Source: SDK 9.0.300
   Manifest Version:    35.0.92/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.92\WorkloadManifest.json
   Install Type:              Msi

[aspire]
   Installation Source: SDK 9.0.300
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

[ios]
   Installation Source: SDK 9.0.300
   Manifest Version:    18.5.9215/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.5.9215\WorkloadManifest.json
   Install Type:              Msi

[maccatalyst]
   Installation Source: SDK 9.0.300
   Manifest Version:    18.5.9215/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.5.9215\WorkloadManifest.json
   Install Type:              Msi

[maui-windows]
   Installation Source: SDK 9.0.300
   Manifest Version:    9.0.82/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.82\WorkloadManifest.json
   Install Type:              Msi

Critical Discovery: .NET Aspire Workload Version Mismatch

MAJOR FINDING: The .NET Aspire workload is installing version 8.2.2 despite:

  • Using .NET SDK 9.0.303
  • Requesting .NET Aspire 9.4.0 in project files
  • Installing via dotnet workload install aspire on .NET 9

Workload Manifest Location Analysis:

aspire workload manifest: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\
Expected for .NET 9:     C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.aspire\9.x.x\

Aspire Workload Manifest Content (8.2.2):

{
  "version": "8.2.2",
  "workloads": {
    "aspire": {
      "description": ".NET Aspire SDK",
      "packs": [
        "Aspire.Hosting.Sdk",
        "Aspire.ProjectTemplates"
      ]
    }
  },
  "packs": {
    "Aspire.Hosting.Sdk": {
      "kind": "sdk",
      "version": "8.2.2"
    },
    "Aspire.ProjectTemplates": {
      "kind": "template",
      "version": "8.2.2"
    }
  }
}

Project Configuration Using .NET Aspire 9.4.0:

<Project Sdk="Microsoft.NET.Sdk">
  <Sdk Name="Aspire.AppHost.Sdk" Version="9.4.0" />
  
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <IsAspireHost>true</IsAspireHost>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.4.0" />
    <PackageReference Include="Aspire.Hosting.Redis" Version="9.4.0" />
    <PackageReference Include="Aspire.Hosting.PostgreSQL" Version="9.4.0" />
    <PackageReference Include="Aspire.Hosting.SqlServer" Version="9.4.0" />
  </ItemGroup>
</Project>

Detailed Manifest Directory Structure Analysis

Complete SDK Manifest Hierarchy:

C:\Program Files\dotnet\sdk-manifests\
├── 8.0.100\
│   └── microsoft.net.sdk.aspire\
│       └── 8.2.2\
│           ├── WorkloadManifest.Aspire.targets
│           ├── WorkloadManifest.json
│           └── WorkloadManifest.targets
└── 9.0.100\
    ├── microsoft.net.sdk.android\35.0.92\
    ├── microsoft.net.sdk.ios\18.5.9215\
    ├── microsoft.net.sdk.maccatalyst\18.5.9215\
    ├── microsoft.net.sdk.macos\15.5.9215\
    ├── microsoft.net.sdk.maui\9.0.82\
    ├── microsoft.net.sdk.tvos\18.5.9215\
    ├── microsoft.net.workload.emscripten.current\
    │   ├── 9.0.7\
    │   └── 9.0.8\    <-- VERSION CONFLICT EXAMPLE
    ├── microsoft.net.workload.emscripten.net6\9.0.7, 9.0.8\
    ├── microsoft.net.workload.emscripten.net7\9.0.7, 9.0.8\
    ├── microsoft.net.workload.emscripten.net8\9.0.7, 9.0.8\
    ├── microsoft.net.workload.mono.toolchain.current\
    │   ├── 9.0.7\
    │   └── 9.0.8\    <-- VERSION CONFLICT EXAMPLE
    ├── microsoft.net.workload.mono.toolchain.net6\9.0.7, 9.0.8\
    ├── microsoft.net.workload.mono.toolchain.net7\9.0.7, 9.0.8\
    └── microsoft.net.workload.mono.toolchain.net8\9.0.7, 9.0.8\

Corruption Signature Analysis

Observable Corruption Patterns:

  1. Multiple Version Conflicts: Same workload with conflicting versions (9.0.7 vs 9.0.8)
  2. Cross-SDK Manifest Pollution: .NET 8 manifests being used by .NET 9 SDK
  3. Incomplete Installations: Partial workload components causing dependency resolution failures

Specific Version Conflicts Identified:

Microsoft.NET.Workload.Emscripten.Current: 9.0.7 vs 9.0.8
microsoft.net.workload.mono.toolchain.current: 9.0.7 vs 9.0.8

Directory Evidence of Dual Versions:

  • microsoft.net.workload.emscripten.current\9.0.7\ AND microsoft.net.workload.emscripten.current\9.0.8\
  • microsoft.net.workload.mono.toolchain.current\9.0.7\ AND microsoft.net.workload.mono.toolchain.current\9.0.8\

.NET Aspire Workload Question Response

"are you doing something with Aspire 8? because you no longer need workload for aspire anymore"

Clarification on .NET Aspire Versions

We were using .NET Aspire 9.4.0, NOT Aspire 8:

<Sdk Name="Aspire.AppHost.Sdk" Version="9.4.0" />
<PackageReference Include="Aspire.Hosting.AppHost" Version="9.4.0" />

Critical Finding: Workload Version Mismatch

ISSUE DISCOVERED: Despite using .NET 9.0.303 SDK and .NET Aspire 9.4.0:

  • Workload system installs Aspire workload version 8.2.2
  • Manifest is located in .../8.0.100/microsoft.net.sdk.aspire/8.2.2/
  • Should be in .../9.0.100/microsoft.net.sdk.aspire/9.x.x/

Evidence of Version Confusion:

Workload Search Result: aspire - .NET Aspire SDK
Actual Workload Installed: version 8.2.2 (from 8.0.100 manifest folder)
Project Configuration: Aspire.AppHost.Sdk Version="9.4.0"
SDK Being Used: .NET 9.0.303

Workload Requirements for .NET Aspire 9.4.0

Current Status: .NET Aspire 9.4.0 DOES require workload installation:

# This was required for our .NET Aspire 9.4.0 project:
dotnet workload install aspire

# Installation included:
Installing Microsoft.Maui.Graphics.Msi.x64 .... Done
Installing Microsoft.Maui.Core.Msi.x64 .... Done
Installing Microsoft.Maui.Controls.Msi.x64 .... Done
# ... additional MAUI and Aspire components

Build Failure Without Workload: When workload was missing, attempting to build .NET Aspire 9.4.0 projects resulted in:

error NETSDK1147: To build this project, the following workloads must be installed: aspire

Detailed Error Message Analysis

Complete Error Context (Pre-Recovery):

C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost>dotnet build
Microsoft (R) Build Engine version 17.14.13+65391c53b for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost\PetReservations.AppHost.csproj : error NU1100: Unable to resolve 'Aspire.AppHost.Sdk (>= 9.4.0)' for '.NETCoreApp,Version=v9.0'.
C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost\PetReservations.AppHost.csproj : error NU1100: Unable to resolve 'Aspire.Hosting.AppHost (>= 9.4.0)' for '.NETCoreApp,Version=v9.0'.
  Failed to restore C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost\PetReservations.AppHost.csproj (in 1.02 sec).

Build FAILED.

Workload Installation Resolution:

PS> dotnet workload install aspire
Installing package 'Aspire.Hosting.Sdk' version '8.2.2'.
Installing package 'Aspire.ProjectTemplates' version '8.2.2'.
Successfully installed workload(s) aspire.

PS> dotnet build
Microsoft (R) Build Engine version 17.14.13+65391c53b for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost\PetReservations.AppHost.csproj (in 2.34 sec).
  PetReservations.AppHost -> C:\github\aspire-beast\PetReservations\src\PetReservations.AppHost\bin\Debug\net9.0\PetReservations.AppHost.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Timeline of Workload Requirements

  • .NET Aspire 8.x: May have removed workload requirements (as mentioned by .NET team)
  • .NET Aspire 9.x: Still requires dotnet workload install aspire as of version 9.4.0
  • Future versions: Workload requirements may change

Post-Recovery Development Experience

What Works Now ✅

After complete .NET SDK reinstall and proper workload installation:

# All basic operations work:
dotnet --version  # 9.0.303
dotnet new webapp # Creates projects successfully
dotnet build      # Builds successfully
dotnet run        # Runs applications

# .NET Aspire specific operations work:
dotnet workload install aspire  # Installs successfully
dotnet new aspire               # Creates Aspire projects
dotnet run (AppHost)           # Orchestrates containers (with Docker)

Current Application Status ✅

  • PetReservations.Web: Blazor Server app builds and runs locally
  • PetReservations.Shared: Core domain models compile successfully
  • Authentication: Cookie-based auth system working
  • UI: Bootstrap 5 responsive interface
  • Mock Services: Temporary backend implementations functional

.NET Aspire Orchestration 🔄

  • AppHost: Requires Docker Desktop running for container orchestration
  • Dashboard: Needs environment variables configured for OTLP endpoints
  • Containers: PostgreSQL, Redis, SQL Server containers defined but need Docker

Comprehensive Technical Recommendations for .NET Team

Immediate Actions Needed

1. Aspire Workload Version Resolution:

  • Issue: .NET 9.0.303 SDK installing Aspire workload 8.2.2 instead of 9.x.x
  • Root Cause: Workload manifest resolution choosing 8.0.100 path instead of 9.0.100
  • Required Fix: Update workload resolution algorithm to prefer SDK-version-matching manifests
  • Urgency: HIGH - This affects all .NET Aspire 9.x users

2. Enhanced Workload Cleanup Commands:

# Current commands are insufficient:
dotnet workload clean      # Only cleans user workloads
dotnet workload clean --all # Fails during corruption

# Needed:
dotnet workload reset --force           # Complete workload reset
dotnet workload diagnose               # Detect corruption
dotnet workload repair                 # Fix corrupted installations

3. Corruption Detection and Recovery:

# New diagnostic commands needed:
dotnet doctor                          # Overall health check
dotnet workload validate               # Validate manifest consistency  
dotnet workload list --verbose         # Show manifest paths and versions
dotnet workload cleanup --corrupted    # Remove only corrupted components

Workload Architecture Improvements

1. Version Isolation:

Current Problem:
C:\Program Files\dotnet\sdk-manifests\
├── 8.0.100\microsoft.net.sdk.aspire\8.2.2\    # Used by .NET 9!
└── 9.0.100\microsoft.net.sdk.ios\18.5.9215\   # Correct structure

Recommended:
C:\Program Files\dotnet\sdk-manifests\
├── 8.0.100\microsoft.net.sdk.aspire\8.2.2\    # Only for .NET 8
└── 9.0.100\microsoft.net.sdk.aspire\9.4.0\    # For .NET 9

2. Manifest Resolution Priority:

  1. Exact SDK version match (9.0.100 for .NET 9.0.303)
  2. Compatible SDK version (9.0.x for .NET 9.0.303)
  3. Fallback to previous version (with explicit warning)
  4. Fail with clear error message (never silent corruption)

3. Installation Verification:

# Post-installation verification needed:
dotnet workload install aspire --verify
# Should check:
# - Manifest version compatibility with SDK
# - Package dependencies resolution
# - Template functionality
# - Build capability test

Error Message Improvements

Current Error (Vague):

error NETSDK1147: To build this project, the following workloads must be installed: 
microsoft.net.workload.mono.toolchain.current

Improved Error (Specific):

error NETSDK1147: Workload dependency conflict detected.

Required: microsoft.net.workload.mono.toolchain.current (version 9.0.8)
Installed: microsoft.net.workload.mono.toolchain.current (version 9.0.7)
Conflict: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\

Resolution:
1. dotnet workload update microsoft.net.workload.mono.toolchain.current
2. dotnet workload clean --force && dotnet workload install aspire
3. For persistent issues: dotnet workload reset --force

Diagnostic info: dotnet workload list --verbose

Development Environment Safety

1. Workload Installation Safety Checks:

# Before installation, verify:
- Existing workload compatibility
- Disk space requirements
- Dependency chain resolution
- Backup current state capability

# During installation, provide:
- Progress indicators with rollback points
- Verbose logging option
- Installation transaction log
- Automatic backup of previous state

2. Multi-SDK Compatibility:

# Test scenarios for workload system:
- Multiple .NET SDK versions installed
- Preview + Release SDK combinations  
- Cross-platform workload sharing
- User vs system-wide installations
- Corporate environment constraints

Monitoring and Telemetry Enhancements

1. Workload Health Telemetry:

// Add telemetry for:
- Workload installation success/failure rates
- Manifest resolution conflicts  
- Cleanup command effectiveness
- Cross-version compatibility issues
- Recovery success patterns

2. Proactive Corruption Detection:

# Background validation service:
dotnet background --validate-workloads
# Should detect:
- Manifest version conflicts
- Missing dependencies
- Corrupted package references
- Orphaned installation artifacts

Documentation and Tooling

1. Enhanced Diagnostic Documentation:

# Add to official docs:
- Workload troubleshooting guide
- Manifest resolution explanation
- Multi-SDK installation best practices
- Corporate environment considerations
- Offline installation procedures

2. Development Tooling:

# New tools needed:
dotnet-doctor.exe              # Comprehensive health check
dotnet-workload-analyzer.exe   # Deep workload analysis
dotnet-recovery.exe            # Automated recovery scenarios

Testing and Quality Assurance

1. Workload System Test Matrix:

Test Scenarios:
├── Single SDK Installation
├── Multi-SDK Environments (8.0 + 9.0)
├── Preview SDK Integration
├── Workload Version Conflicts
├── Partial Installation Recovery
├── Network Connectivity Issues
├── Corporate Proxy Environments
├── Offline Installation Scenarios
└── Cross-Platform Consistency

2. Regression Test Suite:

# Automated tests for:
- Basic workload operations (install/uninstall/update)
- Cross-version compatibility
- Corruption recovery procedures
- Performance impact measurement
- Memory usage validation

Long-term Strategic Improvements

1. Workload Architecture Redesign:

  • Container-based workloads: Isolate workload environments
  • Versioned workload APIs: Prevent breaking changes
  • Dependency resolution engine: Improved conflict resolution
  • Rollback capabilities: Transaction-based installations

2. Developer Experience:

  • IDE integration: Visual workload management
  • Project templates: Workload-aware project creation
  • Automated suggestions: Smart workload recommendations
  • Performance optimization: Faster workload operations

3. Enterprise Readiness:

  • Group Policy support: Corporate workload management
  • Offline packages: Complete disconnected scenarios
  • Security scanning: Workload vulnerability assessment
  • Compliance reporting: Installation audit trails

Technical Details for .NET Team

Corruption Signatures

# These were reliable indicators of workload corruption:
dotnet new console --dry-run  # Would fail
dotnet workload list          # Would show conflicts
dotnet build (any project)    # Would fail with NETSDK1147

Manifest Locations Affected

C:\Program Files\dotnet\sdk-manifests\9.0.100\
├── Microsoft.NET.Workload.Emscripten.Current (v9.0.7)
├── microsoft.net.workload.mono.toolchain.current (expecting v9.0.8)
└── [Multiple other manifests with version conflicts]

Successful Recovery Process

  1. Complete uninstall via Windows Settings
  2. Manual cleanup of residual files
  3. Fresh .NET 9.0.303 installation
  4. Verification of basic functionality before workload installation
  5. Selective workload installation (dotnet workload install aspire)

Current Questions for .NET Team

  1. Workload Roadmap: When will .NET Aspire 9.x remove workload requirements?
  2. Recovery Tooling: Are there plans for better workload corruption recovery tools?
  3. Diagnostic Commands: Could dotnet doctor or similar help diagnose workload issues?
  4. Environment Variables: Is there documentation for all Aspire Dashboard environment variables?

Attachments

  • Working AppHost configuration (simplified for local development)
  • Project files showing .NET Aspire 9.4.0 configuration
  • Error logs from corruption period (if needed)

Report Generated: August 6, 2025 Status: .NET development environment fully restored and functional Next Steps: Complete .NET Aspire container orchestration setup with Docker Desktop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment