I'm building a WPF library in Visual Studio 2015, and build never completes. In build output diagnostic level I can see the last task launched by msbuild is
calling 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\ILAsm.exe' with /nologo "/out:[PathtoOutputDLL]" "[PathtoILfile]" /DLL "/resource=[PathtoResfile]" /debug (TaskId:65)
I can see the ilasm process is hanging around, not crashed, but nothing happens. If I forcefully stop the build by killing the msbuild and launch the same command in a console, it works, fast, outputs Operation completed successfully
I've used Process Monitor to get a handle on what's happening, and I found something weird-ish, when ilasm is successful (run from console), the process is named ilasm.exe and when it's a failure it's named ILAsm.exe (notice the case change), I don't see why, especially that the path to the exe are the same? There is something in the Process event log that mentions prefetch of the binary to be run:
Success: "IRP_MJ_READ","C:\Windows\Prefetch\ILASM.EXE-FD82B157.pf","SUCCESS","Offset: 0, Length: 82 642, Priority: Normal"
Failure: "IRP_MJ_READ","C:\Windows\Prefetch\ILASM.EXE-FD82B157.pf","SUCCESS","Offset: 0, Length: 82 844, Priority: Normal"
Same file but different sizes all of a sudden ?
I still don't know why it's stuck, but I've narrowed it down to bad relationship between a third party COM interop and UnmanagedExports by Robert Giesecke.
That particular class library was dependent on a third party COM interop, and its presence in the IL modified by UnmanagedExports tripped somehow ILASM or UnmanagedExports in ways I don't know. But one thing that unlocked the build is setting "Embed Interop types" to false, so that the COM interop does not end up in the output, then UnmanagedExports works without issues.