GenerateCompiledExpressionsTempFile does not clean up the files it creates

[davkean]

1. Create a new .NET Framework project
2. Build
3. 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

[jeffkl]

Related to #1577, maybe fix them both at the same time?

[rainersigwald]

Unfortunately, like #1646 this is defined in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WorkflowBuildExtensions.targets which doesn't ship with MSBuild and would probably require a framework patch. We'll need to track down whoever owns workflow build internally.

[jeffkl]

Maybe we should set $(GenerateCompiledExpressionsTempFile) to false. 😁

<Target Name ="GenerateCompiledExpressionsTempFile" 
        Condition = "'$(GenerateCompiledExpressionsTempFilePathForEditing)' != ''">  
  <WriteLinesToFile
    File="$(GenerateCompiledExpressionsTempFilePathForEditing)" Condition = "!Exists('$(GenerateCompiledExpressionsTempFilePathForEditing)')" />
  <WriteLinesToFile
    File="$(GenerateCompiledExpressionsTempFilePathForValidation)" Condition = "!Exists('$(GenerateCompiledExpressionsTempFilePathForValidation)')" />
  <WriteLinesToFile
    File="$(GenerateCompiledExpressionsTempFilePathForTypeInfer)" Condition = "!Exists('$(GenerateCompiledExpressionsTempFilePathForTypeInfer)')" />
  <ItemGroup>
    <Compile Include="$(GenerateCompiledExpressionsTempFilePathForEditing)" />
    <Compile Include="$(GenerateCompiledExpressionsTempFilePathForValidation)" />
    <Compile Include="$(GenerateCompiledExpressionsTempFilePathForTypeInfer)" />
  </ItemGroup>  
</Target>

[cdmihai]

@Sarabeth-Jaffe-Microsoft can you please track down who owns this file and move this issue to then?

[Sarabeth-Jaffe-Microsoft]

Bug #392996 created in VSTS under the "DevDiv\Web Platform and Tools\Workflow Tools" area path.

[rainersigwald]

The plan is to fix this by fixing #1646.

[aolszowka]

We were seeing this as well; it appears to be the root cause of causing our 1500 Solution Projects to rebuild upon opening Visual Studio; is there any temporary work around until the actual fix is shipped?

[rainersigwald]

@aolszowka Unfortunately, the fix for creating the files (#1646) required a coordinated change between VS and MSBuild, so I don't think there's a good workaround for VS before 2019 preview 4.

[aolszowka]

@rainersigwald what about inserting the noop target into each one of the 1500 project files? I know that is a huge hammer; but this is really killing our Devs.

[rainersigwald]

That would break VS, which depends on the existence of the files (before 16.0p4).

[aolszowka]

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).

[rainersigwald]

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 think the breakage is limited to the Workflow designer, but I'm not totally confident in that.

your fixes on the Long Path

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.