Build 2.2 causes build error ("child node 2 exited prematurely", IOException, "pipe is broken")

[Sergio0694]

Describe the bug

Updating to the new Microsoft.UI.Xaml package version 2.2 causes the following build error for me:

Child node "2" exited prematurely. Shutting down.

UNHANDLED EXCEPTIONS FROM PROCESS 10252:
=====================
06/09/2019 01:30:38
System.IO.IOException: Pipe is broken.
   at System.IO.Pipes.PipeStream.CheckWriteOperations()
   at System.IO.Pipes.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Update Microsoft.UI.Xaml to 2.2
2. Try to build the app

NOTE: this is happening for me with a specific app, and I'd be happy to give access to the solution to someone from the team to look into it. I've already tried to clean the solution, restart VS, update VS, even tried on 2 different devices, same error. If I try to reproduce this with a blank UWP app, it works just fine and builds with no problems, but I have no clue on what's triggering this in particular in my current app. Due to the nature of the error though, this clearly looks like an issue with the library and not with my actual code (which works just fine with WinUI version 2.1).

Expected behavior

The app should just build

Version Info

NuGet package version:
Microsoft.UI.Xaml 2.2.190830001

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Additional info
I can confirm that this is happening to other developers as well. Here's an error log I got from one of them (which is pretty similar to the one I'm getting):

Error Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in "C:\Users\F8R\AppData\Local\Temp" and will be named MSBuild_*.failure.txt. This location can be changed by setting the MSBUILDDEBUGPATH environment variable to a different directory.
C:\Users\F8R\AppData\Local\Temp\MSBuild_pid-18428_813ed25b544d4e6dbccee0f95f096e6d.failure.txt:

UNHANDLED EXCEPTIONS FROM PROCESS 18428:
=====================
9/5/2019 4:24:44 PM
System.IO.IOException: Pipe is broken.
   at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode)
   at System.IO.Pipes.PipeStream.BeginWriteCore(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)
   at System.IO.Pipes.PipeStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.Pipes.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue'1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================    Rewrite 

[Sergio0694]

So, turns out this isn't caused by WinUI itself, but rather by the SDK 18363 that's breaking my app as well as the app of some other UWP devs. Closing this, since it's off topic with respect to WinUI.

[jevansaks]

@sotteson1 may be able to help with SDK issues. I'm not sure the right place to report them but if it's crashing MSBuild then perhaps filing a bug using the Visual Studio "send feedback" button (in VS itself) may collect the right logs.

[jevansaks]

This is apparently an issue with the SDK as you found. HEre's some more details: https://dvlup.com/2019/08/07/postmortem-child-node-2-compilation-error-after-updating-to-18362-sdk/

And the SDK folks say this is fixed in latest insider SDK flights.

[Sergio0694]

Hi @jevansaks - thank you for following up on this, even though it's not really an issue caused by WinUI. I'm aware of that block post (a couple other MS engineers have linked it to me as well), but unfortunately that hasn't solved the issue for me just yet.
I know the issue has been resolved in the new preview SDK, and apparently the team working on that is considering backporting it to the 19H1 SDK as well, so fingers crossed for that 🤞

Currently there's @LanceMcCarthy that has kindly offered to help and is looking at my repo to reproduce the issue on his end and possibly figure out a way to work around that on the current SDK.

Thank you all again for your time and your help, I really appreciate it!

...And people said the Windows dev community wasn't that great 😄

[michael-hawker]

FYI @jevansaks @ranjeshj hit this same issue or something pretty similar just now on 2004 (it's building fine on another machine with 1909). It's something in this commit range to the sample page xaml file there at the top. I'll try and filter it down a bit more tomorrow.

[michael-hawker]

Yup, I've confirmed it looks like a weird version of the same issue @jevansaks linked to.

As if I add the extra namespaces to the top:

    xmlns:base="using:Microsoft.Toolkit.Uwp.UI.Media.Base"
    xmlns:effects="using:Microsoft.Toolkit.Uwp.UI.Media.Effects"
    xmlns:effectbase="using:Microsoft.Toolkit.Uwp.UI.Media.Effects.Abstract"
    xmlns:int="using:Microsoft.Toolkit.Uwp.UI.Media.Effects.Interfaces"

Then I can build again.

The weird thing though is that it seems to work for others on 1909 targeting the 18362 SDK in VS 2019. However, trying to compile on OS 2004 caused it to break.

I tried retargeting the app to the 19041 SDK and then it worked again! Really really odd.

[Sergio0694]

According to the tracking issue in the VS feedback hub (here), the fact that it builds fine when targeting the 19041 SDK makes perfect sense, as this issue was apparently caused by a XAML compiler bug in the toolchain set for the 18362 SDK. The super weird things though are:

• The fact that I can build that just fine targeting the 18362 SDK, on a W10 19H2 system.
• The fact that for you the build is breaking down just for using W10 20H1 at all.

I'm very confused 🤣

[LanceMcCarthy]

It just seems to come down to using any properties that are only defined on the base class that has no xmlns.

e.g.

namespace MyLibrary.BaseStuff
{
    public class MyBaseControl : UIElement
    {
           public DependencyProperty PixelHeightProperty {...}
           public double PixelHeight {...}
    }
}

and a control that inherits from that:

namespace MyLibrary.Controls
{
    public class MyConcreteControl : MyBaseControl
    { }
}

If you use that control and set the DependencyProperty that is defined in the base...

<Page xmlns:myControls="using:MyLibrary.Controls" >
    <myControls:MyConcreteControl PixelHeight="200" />
</Page>

that replicates the issue.

The workaround is to make sure the compiler has access to the base where the DP is defined:

<Page xmlns:myControls="using:MyLibrary.Controls"
            xmlns:ExcpetionPreventer="using:MyLibrary.BaseStuff">
    <myControls:MyConcreteControl PixelHeight="200" />
</Page>

@michael-hawker Reach out to Alan Wu (WDG), he's the one who discovered the cause and offered the workaround

[michael-hawker]

Also, running a Release mode version of the package built on 1909 worked fine on 2004, so it appears to be purely a build issue.