Visual Studio: Changes in .ts/.tsx files break up-to-date check until full rebuild.

[olmobrutall]

Bug Report

⚠️ ⚠️ Very important performance problem for any TypeScript developer in Visual Studio, specially when using more than one probject ⚠️ ⚠️

TypeScript files afect the build, but do not produce any output in bin/obj, because of this, after succesfully compiling a Web Application (<Project Sdk="Microsoft.NET.Sdk.Web">) that uses the Nuget Microsoft.TypeScript.MSBuild to compile some ts file, if you modify a ts file, the project will be forever ignored by the up-to-date check until a .cs file is changes and a build updates the output dll.

🔎 Search Terms

Visual Studio, UpToDateCheckInput, Microsoft.TypeScript.MSBuild, FastUpToDate, WARNING: Potential build performance issue in

🕗 Version & Regression Information

Visual Studio 2022 64-bits 17.5.3
Microsoft.TypeScript.MSBuild 5.0.4 ( but I think this is old issue)

⏯ Playground Link

I was not sure if the error belongs to TypeScript or VS team. I explained the issue in full here:

dotnet/project-system#8981

[drewnoakes]

The bug here is that the project will never be considered up-to-date, meaning a build will always be scheduled, which can hurt developer inner-loop productivity.

The issues appears to be in the Microsoft.TypeScript.MSBuild package. It should not be exposing TypeScriptCompile MSBuild items as inputs to the up-to-date check, as they do not contribute to the primary MSBuild output (the .dll file).

Perhaps there's a ProjectSchemaDefinition with something like this:

<ProjectSchemaDefinitions xmlns="http://schemas.microsoft.com/build/2009/properties">
  <ItemType Name="TypeScriptCompile" UpToDateCheckInput="True" />
</ProjectSchemaDefinitions>

Instead, TypeScript inputs and outputs should be added to their own "set" as described in https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#grouping-inputs-and-outputs-into-sets

Feel free to reach out if anything's unclear.

[joj]

I'm going to take a look. Can someone provide a binlog that exhibits the issue? I'm not seeing UpToDateCheckInput anywhere in the targets and I don't thing we have TypeScriptCompile in the web sdk (although I didn't check that and it may be the issue).

[drewnoakes]

@joj there are repro steps in dotnet/project-system#8981

You can get a binlog from VS's design-time builds as described in https://github.com/dotnet/project-system-tools#getting-higher-fidelity-logs-from-vs-vs2022-onwards

[drewnoakes]

I don't thing we have TypeScriptCompile in the web sdk

It would be worth checking if the problem exists in a regular .NET Console App that takes a reference on the Microsoft.TypeScript.MSBuild package, with .ts files added. It might be the problem exists solely in that package.

One challenge I can see in solving this is that you'll need to identify an output for TypeScript file(s). Either one per input, or one for all of them (if bundling somehow).

[olmobrutall]

One challenge I can see in solving this is that you'll need to identify an output for TypeScript file(s). Either one per input, or one for all of them (if bundling somehow).

Maybe is enough to use .tsbuildinfo as the output file, or produce warning if incremental is not active?

[joj]

Checking the binlogs, that warning seems to be wrong. CoreCompile is not happening again, CompileTypeScript is not happening again and we have no TypeScriptCompile items in the build. Also, the timestamp of the dll is not changing in that case. I have 3 binlogs: one for a build where there was no recompile triggerred (no warning), one where I changed the ts and there was a rebuild, one right after that with no change but a build reported. In no case was the dll actually changed as far as I can tell. I'm attaching them as a zip.
binlogs.zip

[joj]

@olmobrutall are you seeing the timestamp of the dll (or any other factor) changing in these cases? Maybe I'm checking it wrong :)

[olmobrutall]

Are you able to see the problems activating https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#sdk-style-projects?

I'm not used to binlog but maybe this brings some light:

The way I see it is there are three moving parts:

• Visual studio up-to-date check

  • Input: All cs and ts files
  • Output: Only the dll/pdb

• MSBuild / CSC

  • CS files
  • Output: Only the dll/pdb

• MSBuild / TSC

  • TS files
  • Output: js, sourcemaps etc...

In the csproj / Microsoft.TypeScript.MSBuild.targets the TS files should not be inclided into the default UpToDateCheckInput, because otherwise is compared with the default UpToDateCheckOutput (the dll) that doesn't get updated because the CS compiler doesn't see any change in his CS files.

[joj]

I believe that setting is default for me, I checked and it was set. I'm seeing the same output you're seeing, but the behavior seems right. The output implies something different from what I'm seeing happening. @drewnoakes will be able to check the binlogs (and also, if you have the time I recommend them, they are an amazing tool :)). The quick check for you is: are you seeing the dll change at all (meaning, timestamps or hashes or something) in the case when the ts files are not changing and you still don't get 1 up-to-date in the log?

[joj]

Another small thing: there is no (immediate) way of making msbuild to just CSC or TSC. Clarifying: you can do that if you want, but the behavior is for compile to do both. The thing is TSC will not run if ts files are not changed in relation to js files, and dotnet has a whole bunch of very complex rules. From what I'm seeing in the logs, those behaviors look correct. The output is saying something else, though, and we still need to understand that. That last message I believe is in VS and not in MSBuild, and on that Drew may help.

[olmobrutall]

I believe that setting is default for me, I checked and it was set. I'm seeing the same output you're seeing, but the behavior seems right. The output implies something different from what I'm seeing happening. @drewnoakes will be able to check the binlogs (and also, if you have the time I recommend them, they are an amazing tool :)). The quick check for you is: are you seeing the dll change at all (meaning, timestamps or hashes or something) in the case when the ts files are not changing and you still don't get 1 up-to-date in the log?

No .Net output file has been modified after compiling the application after modifying the ts file, as well as after compiling without modifications. The files are from last saturday when I made the last cs files changes.

This fits with the WARNING produced by Visual Studio up-to-date check.

1>FastUpToDate: Input TypeScriptCompile item 'C:\Users\olmob\source\repos\WebApplication1\WebApplication1\file.ts' is newer (2023-04-21 17:42:07.407) than earliest output 'C:\Users\olmob\source\repos\WebApplication1\WebApplication1\obj\Debug\net7.0\WebApplication1.pdb' (2023-04-15 22:26:56.965), not up-to-date. (WebApplication1)
1>FastUpToDate: Up-to-date check completed in 0,9 ms (WebApplication1)
1>------ Build started: Project: WebApplication1, Configuration: Debug Any CPU ------
1>WebApplication1 -> C:\Users\olmob\source\repos\WebApplication1\WebApplication1\bin\Debug\net7.0\WebApplication1.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build started at 5:42 PM and took 00,492 seconds ==========
WARNING: Potential build performance issue in 'WebApplication1.csproj'. The project does not appear up-to-date after a successful build: Input TypeScriptCompile item 'C:\Users\olmob\source\repos\WebApplication1\WebApplication1\file.ts' is newer (2023-04-21 17:42:07.407) than earliest output 'C:\Users\olmob\source\repos\WebApplication1\WebApplication1\obj\Debug\net7.0\WebApplication1.pdb' (2023-04-15 22:26:56.965), not up-to-date. See https://aka.ms/incremental-build-failure.

[joj]

I just realized that warning actually makes sense, but is absolutely irrelevant. The ts is newer than the pdb. What I'm not seeing in the logs is that item being marked as UpToDateCheckInput. The only things marked as input are some css files: