WPF: CleanupTemporaryTargetAssembly step after MarkupCompilePass2 intermittently fails to delete target assembly

This issue has been moved from a ticket on Developer Community.

---

[severity:Multiple people on my team are impacted (internal MSFT only)] Some WPF projects require a second pass compile, in which a temporary project is generated and then cleaned up. Sometimes, during this compilation, the “CleanupTemporaryTargetAssembly” step fails to perform cleanup successfully due to the target assembly being locked.

Sample error:

MarkupCompilePass2:
  MarkupCompilePass2 successfully generated BAML or source code files.
CleanupTemporaryTargetAssembly:
  Deleting file "Debug\AnyCPU\MyWpfAssembly.dll".
##[error]C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(480,10): Error MSB3061: Unable to delete file "Debug\AnyCPU\MyWpfAssembly.dll". The process cannot access the file 'C:\w\4\s\src\MyWpfAssembly\Debug\AnyCPU\MyWpfAssembly.dll' because it is being used by another process.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(480,10): error MSB3061: Unable to delete file "Debug\AnyCPU\MyWpfAssembly.dll". The process cannot access the file 'C:\w\4\s\src\MyWpfAssembly\Debug\AnyCPU\MyWpfAssembly.dll' because it is being used by another process. [C:\w\4\s\src\MyWpfAssembly\MyWpfAssembly.csproj]
Done Building Project "C:\w\4\s\src\MyWpfAssembly\MyWpfAssembly.csproj" (default targets) -- FAILED.

Other customers have reported the same issue, ex. https://social.msdn.microsoft.com/Forums/en-US/6360a1e3-a269-457c-a763-fb415b8bbf14/quotbecause-it-is-being-used-by-another-processquot-error-has-me-dead-in-the-water?forum=msbuild

---

Original Comments

Feedback Bot on 6/11/2021, 08:22 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Chaitanya Mangalagiri [MSFT] on 8/12/2021, 00:50 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[timmi-on-rails]

Here comes a workaround that solves my (very similar) problem.

After the MarkupCompilePass2 I am even unable to manually delete the DLL that the CleanupTemporaryTargetAssembly also fails to delete with a Access to the path ... is denied. error. I was unable to determine the reason for the access denied error. The command line tool https://docs.microsoft.com/en-us/sysinternals/downloads/handle showed no open file handles. However I am running the build process inside a windows docker container, so maybe the host is locking the file.

The good thing is, I am still able to manually move the problematic DLL file. So I added the following target to the project file. Make sure to replace the file name.

<Target Name="Hack" BeforeTargets="CleanupTemporaryTargetAssembly">
  <Exec Command="move Debug\AnyCPU\MyWpfAssembly.dll Debug\AnyCPU\MyWpfAssembly.txt" />
</Target>

Tell me, if this works for you as well? There is still a chance that my problem is not connected to yours.

[Belpaire]

@timmi-on-rails I’d rather not implement something that is this implementation dependent, as underlying changes in wpf could easily break this solution if it even works in the first place. I did some digging in the source code and only thing I saw that could perhaps be related to what we see is https://github.com/dotnet/wpf/blob/e4ee239b63e7e0fe64b3bada60234c7595158a0d/src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks/MS/Internal/MarkupCompiler/MarkupCompiler.cs#L205-L230, could be that somehow the compiler is locking this assembly with this “ReflectionHelper”, but honestly someone on the wpf team should really look into this issue because we’re not really providing any structural solutions ourselves I’m afraid.