Race Condition in StaticWebAssets with Multi-Targeting and TypeScript Compilation

[loop8ack]

Description

When using multi-targeting (net8.0;net9.0) in a Razor Class Library project that compiles TypeScript files via Microsoft.TypeScript.MSBuild, a race condition occurs during dotnet build. The ResolveProjectStaticWebAssets target sometimes attempts to resolve static web assets before the TypeScript compiler has finished writing the compiled .js files to disk, resulting in an InvalidOperationException.

The error only manifests when multi-targeting is enabled. With a single target framework, the build succeeds consistently.

Reproduction Steps

1. Create a Razor Class Library project with multi-targeting:

   <TargetFrameworks>net8.0;net9.0</TargetFrameworks>

2. Add TypeScript compilation via Microsoft.TypeScript.MSBuild package
3. Configure tsconfig.json to output compiled files to wwwroot/js/dist:

   {
     "compilerOptions": {
       "rootDir": "wwwroot/ts",
       "outDir": "wwwroot/js/dist"
     }
   }

4. Add a TypeScript file in wwwroot/ts/ (e.g., test.ts)
5. Run dotnet build multiple times on Windows
6. The error occurs non-deterministically (race condition)

Sample repository: https://github.com/loop8ack/Dotnet.Issue120620.Reproduction

Expected behavior

The build should succeed consistently.

Actual behavior

The build fails intermittently with:

Microsoft.NET.Sdk.StaticWebAssets.targets(679,5): Error  : System.InvalidOperationException: No file exists for the asset at either location 'D:\Source\...\wwwroot\js\dist\test.js' or 'wwwroot\js\dist\test.js'.
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.StaticWebAsset.ResolveFile(String identity, String originalItemSpec)
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.DefineStaticWebAssets.ResolveFileDetails(String originalItemSpec, String identity)
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.DefineStaticWebAssets.Execute()

Regression?

Unknown. I have not tested whether this occurs in earlier SDK versions.

Known Workarounds

I have implemented a workaround using file-based locking to serialize access to the ResolveProjectStaticWebAssets target:

<Target Name="__RaceConditionFix_AcquireLock_BeforeStaticAssets" BeforeTargets="ResolveProjectStaticWebAssets">
  <AcquireLock LockFile="$(__LockFile)" Timeout="$(__LockTimeout)" />
</Target>

<Target Name="__RaceConditionFix_ReleaseLock_AfterStaticAssets" AfterTargets="ResolveProjectStaticWebAssets">
  <ReleaseLock LockFile="$(__LockFile)" />
</Target>

This forces sequential execution of 'ResolveProjectStaticWebAssets' across target frameworks and appears to work reliably. However:

• This is a hack that shouldn't be necessary
• It adds build time overhead
• It requires custom MSBuild task implementations

Alternative workaround: Remove multi-targeting (use only a single <TargetFramework>) - this eliminates the race condition but is not always feasible.

Configuration

• SDK Version: 9.0.304
• OS: Windows 11 (issue does not occur under Linux)
• Project Type: Razor Class Library (Microsoft.NET.Sdk.Razor)
• Packages:
  • Microsoft.AspNetCore.Components.Web (8.0.* and 9.0.* depending on framework)
  • Microsoft.TypeScript.MSBuild 5.8.3

Project file excerpt:

<Project Sdk="Microsoft.NET.Sdk.Razor">
    <PropertyGroup>
        <TargetFrameworks>net8.0;net9.0</TargetFrameworks>
    </PropertyGroup>
    <ItemGroup>
        <SupportedPlatform Include="browser"/>
    </ItemGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.TypeScript.MSBuild" Version="5.8.3" PrivateAssets="all"/>
        <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="8.0.*" Condition="'$(TargetFramework)' == 'net8.0'"/>
        <PackageReference Include="Microsoft.AspNetCore.Components.Web" Version="9.0.*" Condition="'$(TargetFramework)' == 'net9.0'"/>
    </ItemGroup>
</Project>

Other information

The issue appears to be a timing/ordering problem in the MSBuild target execution graph when multiple target frameworks are being built:

1. With multi-targeting, MSBuild builds each target framework in parallel or in rapid succession
2. The TypeScript compilation (CompileTypeScript target) runs as part of the build process
3. The ResolveProjectStaticWebAssets target attempts to enumerate and validate static web assets
4. There is insufficient dependency declaration or synchronization between these targets
5. When building multiple frameworks, ResolveProjectStaticWebAssets from one framework build can race with CompileTypeScript from another, or the file system operations are not fully synchronized

The race is confirmed by the non-deterministic nature of the failure — it does not occur on every build, only sometimes.

The race condition appears to be Windows-specific. Testing under WSL does not reproduce the issue; conversely, the file-locking workaround causes problems on WSL/Linux.

[loop8ack]

Update: Issue occurs without TypeScript and on both Windows and Linux

I've discovered that this race condition is not specific to TypeScript compilation. The issue also occurs with other MSBuild tasks that generate or modify static web assets, such as Microsoft.Web.LibraryManager.Build.

Key findings:

1. Platform behavior: The race condition occurs on both Windows and Linux (WSL2, Ubuntu), contrary to my initial observation. The frequency of occurrence may vary between platforms.

2. Root cause: The issue is not tied to a specific package, but rather to the fundamental problem that StaticWebAssets processing happens concurrently across multiple target frameworks while asset files are still being generated/modified by other MSBuild tasks.

3. Reproduction: I cannot reliably reproduce the problem when the TypeScript build is installed, presumably due to different sequences in the build process. Without TypeScript, however, it also occurs with Microsoft.Web.LibraryManager.Build or other MSBuild extensions that modify content in the wwwroot folder. Therefore, the reproduction repository includes a second project using LibMan to demonstrate the issue without TypeScript.

4. Error variations: The error can manifest in different forms:

   • Microsoft.NET.Sdk.StaticWebAssets.targets(679,5): No file exists for the asset
   • Microsoft.NET.Sdk.StaticWebAssets.Compression.targets(268,5): The asset '...' can not be found
   • Microsoft.NET.Sdk.StaticWebAssets.targets(615,5): Conflicting assets with the same target path

The core issue is that any MSBuild task generating files in wwwroot can trigger this race condition when combined with multi-targeting and StaticWebAssets processing.

P.S.: Setting BuildInParallel to false does not resolve the issue. While this prevents the target frameworks from building in parallel, the problem still occurs, though less frequently. However, it can still be reliably reproduced using rebuild. This suggests the race condition exists not only between parallel framework builds, but also within the asset processing pipeline of a single framework build.

P.P.S.: I was also able to reproduce the issue with a single target framework (no multi-targeting). This confirms that the problem is not caused by multi-targeting itself.

[oliverw]

We are also experiencing this issue.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

cc @javiercn