WinUI incremental building not working causing a disastrous full build experience

There are a couple of unfortunate things I have noticed over the past weeks and months working on WinUI when it comes to the incremental build process of WinUI.

• While incremental builds work when on the same local branch, unfortunately, as soon as I switch branches and build the project again, Visual Studio is always doing a full build of the project. In fact, further builds will also always be full builds until I do a clean. Only then will incremental builds work again. What that means for my current workflow? Switch a branch -> do a clean -> enjoy a full build to get incremental building working again,

• As soon as I modify an .idl file (like NavigationView.idl) and start a build process, VS always does a full build instead of an incremental build.

WinUI Full build experience is disastrous

Why are full builds a problem here? First, full builds take up to 10 minutes on my Core i7-8750H maxing out my CPU during most of the time. Secondly, and most importantly, the VS build process consistently runs out of memory at some point during the build process. I am particularly dreading the moment the compiler reaches the following files during the build process:

ScrollInputHelper.cpp
ScrollPresenter.properties.cpp
ScrollControllerInteractionRequestedEventArgs.cpp
ScrollControllerScrollByRequestedEventArgs.cpp
ScrollControllerScrollFromRequestedEventArgs.cpp
ScrollControllerScrollToRequestedEventArgs.cpp
ScrollPresenter.cpp

When the VS compiler reaches these files, the RAM consumed by it jumps significantly, so much that VS often runs out of memory here and outright cancels the build task. This happens with me making sure that VS has at least 8 GB if not 9 GB of RAM available before starting a build process. And to be clear, these are not the only files in the build process causing the out of memory issue but that issue does occur more often than not at this stage in the build process.

I think I don’t have to tell you that this experience is really frustrating. Especially as VS was already building for a few minutes here until it runs out of memory. In other words: I just completely wasted my time.

Case in point, yesterday, two simple commits took 45 minutes of my time because I just couldn’t get VS to finish building the project here (so I could quickly verify their correctness in the MUXControlsTestApp). This is unacceptable and absolutely detrimental to get anything done in WinUI.

While the root cause of the build failure always seems to be VS running out of memory, the reported error messages vary a bit. Here are the three different types of errors I have seen (writing them out of my memory here so those will lack details):

• PCH - The compiler ran out of heap space
• System.OutOfMemoryException - VS just cancels the task build (that’s the one I often see occuring around the Scroll*.cpp files above)
• Internal C++ compiler error - Please contact the VS team (seems to happen rather rarely)

Nearly 50% of my full builds end in such failures and when such a failure happens, all bets are off. VS needs to be restarted, and I even had to restart Windows (!) at one point. More time being wasted here getting nothing done…

Note that the specific System.OutOfMemoryException error I mentioned above only started occuring since a few days ago. I am not aware of any VS or Windows update I did over the past week which could have contributed to that. I use VS and Windows in the following versions:

• Windows 10 19041
• Visual Studio 16.6.2

How to improve the WinUI build story

So, ideally, these issues could be solved and the WinUI development experience significantly improved by achieving the following:

• Switching (local) branches won’t require a full build of the project. Instead, incremental building will keep working.
• Modifying IDL files also won’t cause a full build of the project and use incremental building instead.

When incremental building works, building WinUI does not take away the fun of working on it. When it doesn’t - especially in common cases like the ones mentioned above - the WinUI development experience is disastrous and takes away all the fun.

I’m not sure if this is something the WinUI team can fix or if we need some VS folks to help out here. If it’s the latter, I’d hope that the WinUI team can put some emphasis on these issues internally at MS so that the WinUI build process in VS can be improved in a timely manner. I’m hardly one to press for immediate action on this repo but I have to say these past days have just been incredibly frustrating.

[Felix-Dev]

@ranjeshj Nice! That solves the missing API tests:

While the specific NumberBox interaction tests still fail to find the NumberBox instance I have tested other interaction tests just now, like NavView interaction tests, and they work fine. Perhaps I made a recent change to the NumberBox test page which I do not recall right now which is causing the NumberBox issues.

[robloo]

This is definitely a significant barrier to contributions. This and being written in the strangest mix of C++/IDL/Generated Code I’ve seen in a long time – I miss ‘pure’ architectures and C#.

That said, we really should add minimum and recommended system requirements to the documentation somewhere, I’m still not sure what Microsoft is using internally to make building more reasonable but they must be some pretty powerful systems.

Long-term, a lot of optimizations and changes are needed to improve the build experience across the board.