MsBuild: Target `TypeScriptDeleteOutputFromOtherConfigs` can grab tsc.out from other Configuration

[nvirth]

Bug Report

If you build an MsBuild project using the nuget package microsoft.typescript.msbuild, there is a target named TypeScriptDeleteOutputFromOtherConfigs which runs before CompileTypeScript.
This target aims to delete tsc...out files from other "configs" then the "current", whatever that means.

In case you build the project in Debug mode, there will be a file created:

/obj/Debug/<TargetFramework>/Tsc<RandomNumber>.out".

Now if you build this project in Release mode:

/obj/Release/<TargetFramework>/Tsc<RandomNumber>.out".

However this 2. build in Release mode will grab the previous Tsc....out from the Debug folder. It will delete all the previously built files listed in that file.

Target TypeScriptDeleteOutputFromOtherConfigs uses property $(BaseIntermediateOutputPath) which is like ...full path to project...\obj\.
I don't really understand what this Target aims to do; but couldn't it use propery $(IntermediateOutputPath) which is like obj\<Configuration>\<TargetFramework>\?
That way the above issue could be avoided.
I would think it could not cause any harm since this Tsc....out file is written by the TypeScript targets which by me always put this file into obj/Debug or obj/Release, never outside of these.

🔎 Search Terms

TypeScriptDeleteOutputFromOtherConfigs

🕗 Version & Regression Information

It is sure present in:

microsoft.typescript.msbuild v4.4.4
microsoft.typescript.msbuild v4.8.1-rc

🙁 Actual behavior

The 2. build in Release mode grabbed the previous Tsc....out from the Debug folder, and deleted all the previously built files listed in that file.
This causes the previously built files to get deleted unnecessarily.
In our project structure - which is complex and tricky - it also causes a build error.
(We have a workaround for that, we simply override target TypeScriptDeleteOutputFromOtherConfigs to do nothing; so this issue is only for the benefit of the community.)

🙂 Expected behavior

Don't really know when TypeScriptDeleteOutputFromOtherConfigs could be helpful, but it (maybe) should only scan for Tsc....out files in obj/<TargetFramework>

[sergiocastelani]

Hello @nvirth! Could you share how you override the target TypeScriptDeleteOutputFromOtherConfigs? We are experiencing the same problem here with microsoft.typescript.msbuild 5.4.5.

[sergiocastelani]

Here is a tiny abstract project that reproduces the problem, causing the build to fail with the error:

\Microsoft.TypeScript.targets(712,5): error MSB3061: Unable to delete file "...". Access to the path '...' is denied

Just compile it with dotnet build -m:12 WebApplication.sln until it happens (around 20% of the times for me).
The more frameworks we try to build in parallel the bigger are the chances to hit the problem.
If we compile for only one framework, like dotnet build -f:net8.0 -m:12 WebApplication.sln, the problem won't happen.

sampleProject.zip

[joj]

Hi! I'm not fully understanding what the issue is. That target is designed to be a full cleanup. "Configuration" in this case means "Debug" or "Release". The target is working as designed. How is this target affecting your workflow? I want to more fully understand the scenario to understand how we can redesign to help in your case. Thanks! J

[silvath]

@joj if you download the sampleProject that @sergiocastelani put in the comment below you will see the problem.
I think that its a concurrency problem. It not happen always. Try to run dotnet build a few times and you will see the problem

#50428 (comment)

[sergiocastelani]

@joj! Besides the original concern and analysis of @nvirth be related to Debug builds touching Release artifacts and vice versa, I believe that the build error he mentioned :

In our project structure - which is complex and tricky - it also causes a build error.

happens because the TypeScriptDeleteOutputFromOtherConfigs is going beyond that and deleting artifacts from other target frameworks too. Put that behavior in a concurrent build and the chaos is established. My sample project is a proof for that.

[joj]

Is the workaround of overriding the targets applicable to you folks? From what I can see in the history, this behavior has existed for as long as I do have history. I can add a condition (DeleteOtherConfigurations defaulting to true, or something) but that will only apply to 5.8 and later. We probably won't add new features to something as old as 4.x.

[sergiocastelani]

We couldn't find a way to override TypeScriptDeleteOutputFromOtherConfigs.
If you can suggest a functional workaround for #50428 (comment) , that would suffice for us.

The proposed DeleteOtherConfigurations can be a good solution, as long as the targets don't touch, when DeleteOtherConfigurations=false, the artifacts of other traget frameworks too. For example, net6.0/Release and net8.0/Release will build concurrently with the same configuration (Release).

Hoewever, I believe that there is no need to create a new condition. Adjusting the TypeScript targets to never touch the artifacts of other traget frameworks would be the best option.

We also see no problem if the fix comes only for next versions.