Certain MSBuild configuration causes _wpftmp build output directories to not be deleted after each build

[nathan-alden-hp]

.NET Core 3.1.201
Windows 10 build 18363

Problem description:

Certain MSBuild configuration causes the compiler to leave behind directories with a _wpftmp suffix after a build completes. The problem seems to be related to custom <BaseOutputPath>s.

Actual behavior:

Temporary output directories are left behind after every build. A new directory is created per build.

Expected behavior:

Temporary output directories are deleted after every build.

Minimal repro:

WpfApp1.zip

[jonesdwg]

Just confirming this is still an issue with 3.1.301. Only impacts WindowsDesktop sdk projects. In our case we have a custom <OutputPath>

[vatsan-madhavan]

This is not a bug; By Design AFAICT.

Deleting build artifacts generated by the temp projects had never been a goal.

The only goal has been deleting the *wpftmp.csproj itself, because it is created alongside the original project inside the cone of the sources directory.

Depending on various build configuration choices, the output directories can be named after either (a) the target assembly or (b) the project name (or something else, which is uncommon).

When (a) is in effect, the *wpftmp.csproj project will simply happen to use the same folders under $(Obj) and $(Bin) as the original project - they happen to share the same target assembly name by design.

When (b) is in effect, msbuild will provision *wpftmp.csproj with its own folders under $(Obj) and $(Bin) based on the project name.

This works the same in .NET Framework and .NET Core; in SDK style projects and in older style projects.

[jonesdwg]

That's interesting, thanks. In our case however this does only seems to be impact WindowsDesktop sdk projects.

I've modified the solution provided by @nathan-alden-hp to include a wpf .net framework project and .net core console app: repro.zip

These all pick up their output path from the Directory.build.props, but it's only the sdk style WindowsDesktop project that leaves behind the temporary directories:

From what I understand I'm probably falling into scenario b as both the output path and intermediate path are modified based on the $(MSBuildProjectName)

<BaseArtifactsPath>$(MSBuildThisFileDirectory)artifacts\</BaseArtifactsPath><OutputPath>$(BaseArtifactsPath)bin\$(MSBuildProjectName)\</OutputPath> <BaseIntermediateOutputPath>$(BaseArtifactsPath)obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>

NB: I only see these extra directories left over in the bin directory, the obj directory is behaving as expected.

This does feel like a bug (or at least undesirable behaviour) and only started happening once we migrated our WPF apps to SDK style projects.

That said, I can work around it easily enough, by adding a post build step in Directory.build.targets to delete the directories:

<Target Name="RemoveWpfTemp" AfterTargets="Build"> <ItemGroup> <WpfTempDirectories Include="$([System.IO.Directory]::GetDirectories(&quot;$(BaseArtifactsPath)bin&quot;,&quot;$(MSBuildProjectName)_*_wpftmp&quot;))"/> </ItemGroup> <RemoveDir Directories="@(WpfTempDirectories)" /> </Target>

[nathan-alden-hp]

I'm not sure why it should even be "by design" for a build system to repeatedly generate new directories that appear to never be cleaned or wiped...

[msedi]

Honestly, I also don't agree that temporary files and directories will not be deleted after the build has finished.
Also it is not deterministic when and why this happens. We changed some small detail in the project and we even don't know which option we have changed that it came to this behavior.

[dotMorten]

This behavior has been driving me nuts as well. This shouldn't be by-design. No other project type does this.

[msedi]

Any news on this?

[chipplyman]

I confirm that this bug also affects non-SDK .NET Framework projects, as suggested by the last paragraph of vatsan-madhavan's comment from Jul 3, 2020.

I disagree with the assessment that it is not a bug. Even if the implementation is operating as designed, that merely shifts the root cause of the bug from the implementation to the design. This arguably makes it more a severe bug since it could have been caught earlier in the production pipeline and was not.

[nathan-alden-sr]

I created this post-build target to deal with these folders:

<!--
  Delete temporary compiler output caused by this bug:
  https://github.com/dotnet/wpf/issues/2930
-->
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <Exec Command="FOR /D %%G in (&quot;$(BaseOutputBinPath)*_*_wpftmp&quot;) DO RMDIR /S /Q &quot;%%~G&quot;" />
</Target>

[msedi]

Any news on this?

[HermanEldering]

I'm running into this issue as well. For those that want to investigate the issue themselves I believe this is where the problem originates and where the files but not directories are deleted: GenerateTemporaryTargetAssembly

The way I've worked around is by adding an extra <OutputPath> in my directory.build.props file, which has a condition like this:

<OutputPath Condition="$(MSBuildProjectName.EndsWith('_wpftmp'))">
    $(OutputBase)\Temp\tmpwpf\$(MSBuildProjectName)
</OutputPath>

Then there is a task to delete my entire tmpwpf folder so no artifacts are left behind.

Perhaps this is also a good solution for the WPF team? Just store the wpftmp projects somewhere else and delete that entire folder, instead of enumerating the files and deleting each one. It could be just a special subdirectory in the BaseIntermediateOutputPath or perhaps even a random directory in %temp%.

There are some other places in MSBuild that use the generated project name, so even if it is inside a new random directory the project name should perhaps remain like it is.

[ThomasGoulet73]

OutputPath is never used, it uses IntermediateOutputPath to get the path of the assembly to build in GenerateTemporaryTargetAssembly. The folder created at OutputPath is created by PrepareForBuild but from what I can see, it's never used. This is the same bug as #5711. The problem is that it's evaluating properties with different values than the main build. We can't really evaluate every properties before the build in GenerateTemporaryTargetAssembly because it would break other projects that rely on the evaluation of properties inside GenerateTemporaryTargetAssembly . I have a potential fix that I'm experimenting with right now. It's working but I have to do more tests to make sure that I'm not breaking anything.

[msedi]

And there is also an $(OutDir)... which we needed to set to $(OutputPath) to make our things work.

[HermanEldering]

@ThomasGoulet73 Those are good points you're making, I'll wait to see how your fix progresses.

[msedi]

Any news on this?

[lindexi]

@msedi It looks like VS2022 will try its best to clean out these folders...

[msedi]

@lindexi: Thx. Do you know which version. I'm having the latest official version. Are you using the previews?

[msedi]

Even with the latest Visual Studio preview the problem still exists (more than 2 years after....) 👎

[Wolf-K]

@lindexi: We are using VS 2022 17.2.5 and just noticed that our project folders are also polluted by random _wpftmp project files. Unfortunately all these files are also published to Github.

[msedi]

Obviously the problem still isn't solved. Within 7 days my directory for one wpf library is polluted with 186 wpftmp folder. Is there any progress now?

[msedi]

What is the status?

[chipplyman]

I successfully worked around this issue by replacing:
<OutputPath>some\path\including\$(MSBuildProjectName)\</OutputPath>
with
<OutputDirectory>$(MSBuildProjectName)</OutputDirectory>
<OutputDirectory Condition=" '$(AssemblyName)' != '' ">$(AssemblyName)</OutputDirectory>
<OutputPath>some\path\including\$(OutputDirectory)\</OutputPath>

Obviously this will not work for you if you need $(AssemblyName) to differ from $(MSBuildProjectName).

[msedi]

@chipplyman: You are right, I need the $(AssemblyName) otherwise I would get too many write problems since with the multithreaded built to many files of the same name would be copied into the global target directory.

[yamithrain]

Any news?

[lindexi]

@yamithrain Could you test VisualStudio 2022 17.6.5 ?

[yamithrain]

The issue is still present with 17.6.6.

[lindexi]

Sad...

[msedi]

I also still have this problem in the latest preview: 17.8.0 Preview 1.0

[luttje]

I also ran into this issue. I found the problem to be caused by:

<BaseOutputPath>..\..\bin\$(MSBuildProjectName)</BaseOutputPath>

In order to fix those *_wpftmp folders being created I've resorted to using this instead:

<BaseOutputPath>..\..\bin\$(AssemblyName)</BaseOutputPath>

I'm unaware of any side-effects with this configuration. Everything seems to work fine.

More (possibly relevant) information about my setup:

• SDK-style project file
• NET Framework 4.8
• WPF UserControl
• Output type:

  <OutputType>Library</OutputType>

• References:

  <Reference Include="PresentationCore" />
  <Reference Include="PresentationFramework" />
  <Reference Include="System.Xaml" />
  <Reference Include="WindowsBase" />

Edit: Only after posting this did I notice someone above already mentioned this workaround:

I successfully worked around this issue by replacing:
<OutputPath>some\path\including\$(MSBuildProjectName)\</OutputPath>
with
<OutputDirectory>$(MSBuildProjectName)</OutputDirectory>
<OutputDirectory Condition=" '$(AssemblyName)' != '' ">$(AssemblyName)</OutputDirectory>
<OutputPath>some\path\including\$(OutputDirectory)\</OutputPath>

Obviously this will not work for you if you need $(AssemblyName) to differ from $(MSBuildProjectName).

[AFract]

I am here due to the same problem (.Net 7.0, VS2022 17.8.5). I have thousands of those *wpftmp folders in my build folder...
I have a directory.build.props in my solution, I guess it is indirectly related.
Any structural update on it ?
Thank you

[lindexi]

@AFract What is your code in Directory.Build.Props ?

[AFract]

Hello, thank you for answering.
Here's the important part :

<Project>
	<PropertyGroup>
		<Version>1.0.0.0</Version>
		<AssemblyVersion>1.0.0.0</AssemblyVersion>
		<FileVersion>1.0.0.0</FileVersion>
		<IntermediateOutputPath>$(SolutionDir)Build\$(MSBuildProjectName)\obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
		<OutputPath>$(SolutionDir)Build\$(MSBuildProjectName)\bin\$(Platform)\$(Configuration)\</OutputPath>
		<Platforms>x64</Platforms>
		<Configurations>Debug;Release</Configurations>
	</PropertyGroup>
	<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|Any CPU'">
		<PlatformTarget>x64</PlatformTarget>
		<Optimize>true</Optimize>
		<DebugType>none</DebugType>
	</PropertyGroup>
	<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|Any CPU'">
		<PlatformTarget>x64</PlatformTarget>
		<DebugSymbols>true</DebugSymbols>
		<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
	</PropertyGroup>
</Project>

[lindexi]

@AFract Sorry, I can not repeat the problem with your Directory.Build.Props. And I think that there are other preconditions I don't know about.

Could you provisionally remove the <OutputPath> property in Directory.Build.Props to test? Maybe there can be fewer folders created.

[chibanemourad]

To resolve this bug, you have the choice between:

Redefine the property <AssemblyName> individually in each of your WPF csproj files as follows:

<AssemblyName>Your_Assembly_Name</AssemblyName>

Alternatively, in a more global way, Redefine the ProjectFriendlyName property in a Directory.Build.props file as follows:

<PropertyGroup Condition="$(ProjectFriendlyName.EndsWith('_wpftmp', StringComparison.CurrentCultureIgnoreCase))">
    <ProjectFriendlyName>$([System.IO.Path]::GetFileNameWithoutExtension($(ProjectFriendlyName)))</ProjectFriendlyName>
</PropertyGroup>