WPF Temporary Project Caches Stale Type Metadata, Making Project Unbuildable

[Th0rGarden]

Description

WPF Temporary Project Caches Stale Type Metadata, Making Project Unbuildable

Summary

WPF's temporary assembly generation (*_wpftmp.csproj) caches type metadata that becomes permanently stale when properties are added to existing classes. The cache survives all standard clearing operations, system restarts, and even property renaming, making the project completely unbuildable. No documented method exists to clear this cache.

Environment

• Visual Studio: 2022 Community (17.0)
• .NET SDK: 8.0.306
• Target Framework: net8.0-windows
• Project Type: WPF + Windows Forms hybrid using Microsoft.NET.Sdk
• Compiler: Roslyn 4.14.0-3.25412.6
• OS: Windows 11

What Makes This Critical

The Cache is Indestructible

We attempted every documented cache-clearing method with no success:

Standard Operations (All Failed):

• dotnet clean
• Manual deletion of bin/ and obj/ folders
• Deleted all *_wpftmp* directories
• Killed all MSBuild and devenv processes
• Full system restart

Advanced Cache Clearing (All Failed):

• Deleted C:\Users\<User>\AppData\Local\Temp\Roslyn\
• Deleted C:\Users\<User>\AppData\Local\Temp\MSBuildTemp\
• Deleted C:\Users\<User>\AppData\Local\Microsoft\VisualStudio\17.0_*\Roslyn\ (entire folder)
• Deleted C:\Users\<User>\AppData\Local\Microsoft\VisualStudio\17.0_*\Designer\Cache\
• Deleted C:\Users\<User>\AppData\Local\Microsoft\VisualStudio\17.0_*\ComponentModelCache\
• Deleted solution .vs folder
• Ran dotnet nuget locals all --clear

Workarounds Attempted (All Failed):

• Renamed property from ToolResults to Results (cache rejected BOTH names)
• Incremented assembly version to 2.0.0.0
• Deleted and recreated the source file
• Updated file timestamps
• Set <GenerateTemporaryTargetAssembly>false</GenerateTemporaryTargetAssembly> (broke XAML compilation)
• Created separate class library project (cache still used old definition)
• Excluded files from compilation

The Cache is Adaptive

When we renamed the property to work around the cache, the cache learned the new name and rejected it too. This suggests the cache is actively comparing against a stored snapshot rather than just missing an update.

Impact

This bug makes WPF projects completely unbuildable when certain type changes occur. The only known solutions are:

1. Complete reinstall of Visual Studio + .NET SDK
2. Build on a different computer
3. Wait for cache to expire naturally (timeframe unknown)
4. Keep new functionality permanently disabled

Root Cause Analysis

The WPF temporary project generation system (GenerateTemporaryTargetAssembly target) creates a temporary .csproj file during CoreCompile for XAML type resolution. This process caches type metadata in an undocumented location that:

• Survives all standard cache-clearing operations
• Survives system restarts
• Survives file deletion and recreation
• Survives assembly version changes
• Is not cleared by any documented MSBuild or Roslyn cache-clearing method

Evidence

From detailed MSBuild output, we confirmed:

• Models\AIResponseChunk.cs is included in the main project compile list
• The source file contains the property (verified via file inspection)
• Visual Studio IntelliSense recognizes the property
• The WPF temp project (Redline_xxxxx_wpftmp.csproj) fails to recognize it

Request

1. Document the cache location so developers can clear it manually
2. Provide a reliable cache-clearing mechanism (e.g., MSBuild property or command)
3. Fix the cache invalidation logic to detect type changes
4. Add cache expiration to prevent permanent staleness

Additional Context

• This appears to affect recently added properties specifically - older properties in the same class work fine
• The issue may be related to Roslyn's type metadata caching interacting with WPF's temporary assembly generation
• Similar issues reported in .NET 8 WPF projects but no documented resolution
• The cache appears to store complete type snapshots rather than incremental changes

Workaround That Should Work (But Doesn't)

According to community suggestions, moving the affected classes to a separate class library should bypass the cache since the temp project would reference the compiled DLL. This did not work - the cache still used the old type definition even when referencing an external assembly.

This is a critical bug that needs urgent attention as it makes WPF development unreliable and unpredictable.

Reproduction Steps

1. Create a .NET 8 WPF project with a model class:

namespace Redline.Models
{
    public class AIResponseChunk
    {
        public string? Text { get; set; }
        public List<ToolCall>? ToolCalls { get; set; }
        public bool IsComplete { get; set; }
    }
}

2. Build the project successfully
3. Add a new property to the class:

public List<ToolResult>? ToolResults { get; set; }

4. Reference the new property in code:

yield return new AIResponseChunk
{
    ToolResults = savedToolResults,
    IsComplete = false
};

5. Attempt to build

Expected behavior

Project should build successfully with the new property recognized.

Actual behavior

Build fails with errors from WPF temporary project:

error CS0117: 'AIResponseChunk' does not contain a definition for 'ToolResults'
error CS1061: 'AIResponseChunk' does not contain a definition for 'ToolResults' and no accessible extension method...

The property exists in the source file and is visible in Visual Studio IntelliSense, but the WPF temporary project (Redline_xxxxx_wpftmp.csproj) uses a cached version without the new property.

Regression?

No response

Known Workarounds

No response

Impact

No response

Configuration

No response

Other information

No response