Skip to content

Rebuild fails when fingerprinting compiled TypeScript in VS 17.12.0 #58948

Closed
@kaleidocore

Description

@kaleidocore

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

After upgrading to VS 17.12.0 / .Net9 SDK: Solution Rebuild fails during fingerprinting of static assets, if those assets are (re-)produced during build.

In particular this applies to TypeScript files that are compiled to .js files under wwwroot/ during the build process, using the standard Microsoft.TypeScript.MSBuild (5.6.2) nuget.

This worked in VS 17.11.x / .Net8 SDK.
The project is a .Net8 project.

NB: It is also unclear why fingerprinting is even applied to .Net8 projects, and how to turn it off.

Expected Behavior

Rebuild should not fail. Analysis of static assets produced during build should be scheduled so that fingerprinting succeeds.

Steps To Reproduce

Minimal repro here: https://github.com/kaleidocore/TSBuildFail

The minimal repro is based on the basic TypeScript template/example described here: https://learn.microsoft.com/en-us/visualstudio/javascript/tutorial-aspnet-with-typescript?view=vs-2022

Typically Clean+Build succeeds, but Rebuild fails.

Exceptions (if any)

System.InvalidOperationException: No file exists for the asset at either location 'wwwroot\js\app.js' or 'wwwroot\js\app.js'.
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.StaticWebAsset.ComputeFingerprintAndIntegrity(String identity, String originalItemSpec)
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.DefineStaticWebAssets.Execute()

.NET Version

9.0.100

Anything else?

Other static assets produced during build also fails in the same way, e.g. .scss -> .css using WebCompiler.

A temporary workaround for the issue is to force a downgrade of the .Net SDK using a global.json in the root folder:

{
	"sdk":
	{
		"version": "8.0.404",
		"rollForward": "latestPatch"
	}
}

I believe the core of this issue is actually much older, but the new Fingerprinting feature puts focus on it by failing completely, whereas it previously sort of "worked" - we have had very similar issues when publishing our projects (dotnet publish solution.sln ...) in previous versions of Visual Studio / .Net. It often appears random or timing based whether those same static files produced during build are actually included in the publish output. We've had to work around it by adding additional build steps such as Clean, Build, Publish and running it single-threaded.

I also suspect these issues are related:
#57147
#58748

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions