GenerateCompiledExpressionsTempFile does not clean up the files it creates
See original GitHub issue- Create a new .NET Framework project
- Build
- Clean
Expected: Obj to be empty Actual: 3 files generated by GenerateCompiledExpressionsTempFile are still present:
TemporaryGeneratedFile_036C0B5B-1481-4323-8D20-8F5ADCB23D92.cs
TemporaryGeneratedFile_5937a670-0e60-4077-877b-f7221da3dda1.cs
TemporaryGeneratedFile_E7A71F73-0F8D-4B9B-B56E-8E70B10BC5D3.cs
Issue Analytics
- State:
- Created 7 years ago
- Comments:12 (9 by maintainers)
Top Results From Across the Web
Why doesn't CMake-generated make clean delete files ...
It seems this may happen if the files are generated under the source folder rather than under the build folder. I think CMake...
Read more >latexmk cleanup after complile and do not clean synctex files
I am trying to make latexmk cleanup after compiling. But I have 2 problems: latexmk -pdf -c xx.tex only does the cleaning but...
Read more >Disk cleanup in Windows 10 is not removing selected files
Disk Cleanup deletes temporary files and system files, empty the recycle bin and remove a variety of other items that you might no...
Read more >Clean task does not clean up specified outputs.file
I got confirmation from the source code that the clean task simply deletes the build directory. It assumes that you want to clean...
Read more >File history not deleting old files to make space for new ones.
To clean older File History backups manually, open Control Panel → File History → Advanced settings → click "Clean up versions." However, if ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

I think the breakage is limited to the Workflow designer, but I’m not totally confident in that.
Can’t take much credit for this; ccastanedaucf did the actual work there. Also note that the changes there don’t apply inside VS so you’re likely to continue to need output-path gymnastics for a while yet.
When you say “Break VS” what do you mean? Is it a livable situation if we do not use Workflow (I do not believe we do; but maybe there is something I am missing here). I just tested it and as far as I can tell I am getting an incremental build now.
Thank you for all the hard work you’ve been doing your fixes on the Long Path are also fixing another issue that we’re encountering wherein the state files previously were not being written (we’re working around that too by putting our IntermediateOutputPath basically in to the root of the C Drive and then flattening it out from there). Long term we just need to get to VS19/MSB16, because it includes tons of these changes I know, but this is just absolutely killing us (60 Devs; 200 in the whole company).