Happy Holidays (aka Dec Update for WPF on .NET Core )

[vatsan-madhavan]

Happy Holidays (aka Dec Update for WPF on .NET Core )

We recently announced .NET Core 3.0.1. Although this is a small update, it has significant bug-fixes. We also just released .NET Core 3.1, which will be an LTS release.

Since our last update, the WPF team has fixed several bugs and has started work that will continue onto the next year.

Thematically, the work we have been doing over the past several weeks can be categorized into improvements in the following focus areas:

• High DPI
• Accessibility
• SDK
• WPF Samples

High DPI

All issues noted below assume that applications are manifested for high-DPI.

• When moving applications from one monitor to another, the insertion caret sometimes disappears. (WPF TextBox insertion caret does not render when moved to lower DPI monitor in a PMAv2 process #1774).
  • @SamBent found that the OS doesn't scale SPI_GETCARETWIDTH like it does with other metrics, and added a fix to scale it appropriately before using it in WPF.
• Sometimes, Context Menus fail to be displayed correctly, aren't displayed at all (Context Menus (Popup) are sometimes broken in High-DPI applications in .NET 4.8  #2088); or seemingly lose their DataContext (ContextMenu loses DataContext when DpiAwareness is activated #2172).
  • We found that a recent change inherited from .NET 4.8 had called into a helper method to destroy an HWND which also performed additional work and resulted in unexpected side-effects. It was fixed by limiting the scope of the work done to destroy the HWND.
• Applications that host native windows via HwndHost in a mixed-DPI context (i.e., the HwndHost hosted window is marked as DPI_AWARENESS_CONTEXT_SYSTEMAWARE, for e.g.), sometimes crash with KeyNotFoundException (NULL HWND's attempted to be parented under SystemResources listener window cause unhanded exception #2089)
  • The full explanation of the root-cause and the fix can be found at Prevent NULL HWND's from being parented under SystemResources listener windows #2100.

SDK

• We missed including a few important types like ObservableCollection in our reference-assemblies in the 3.0.100 SDK (WindowsBase ref-assembly is missing some type forwards #1964). We appreciate the help of all the community members who brought this to our attention, and your patience with us while we worked on getting a fix out.

  • @rladuca has since fixed this via Fix missing type forwards in reference assemblies (3.0 port) #2011 and the 3.0.101 SDK should have a complete set of API reference surface.

• As part of porting WPF to .NET Core, we built an updated version of the markup compiler (which is contained in PresentationBuildTasks.dll). Although it is largely similar to the one that ships with .NET Framework, there are significant differences as well. This new version of PresentationBuildTasks.dll ships with the .NET Core SDK. In fact, there are copies of the DLL that we ship with the Microsoft.NET.Sdk.WindowsDEsktop SDK - tools\net472\PresentationBuildTasks.dll used by MSBuild and Visual Studio, and tools\netcoreapp2.1\PresentationBuildTasks.dll used by dotnet builds. @ryalanms found during internal testing that the SDK was not correctly using tools\net472\PresentationBuildTasks.dll, and was instead incorrectly utilizing the .NET Framework's copy of PresentationBuildTasks.dll (typically found under %windir%\Windows\Microsoft.NET\Framework\v4.0.30319\WPF). Visual Studio and MSBuild net4x TFM builds use legacy PresentationBuildTasks.dll when using WindowsDesktop SDK #1998

  • @vatsan-madhavan fixed this via Visual Studio and MSBuild net4x TFM builds use legacy PresentationBuildTasks.dll when using WindowsDesktop SDK #1998, and had much help from @rainersigwald, @nguerrera and @ryalanms . We learned that UsingTask in MSBuild is a 'first-one-wins' construct (MSBuild: UsingTask is first-one-wins MicrosoftDocs/visualstudio-docs#4040).
  • For those of you used to seeing WinFX.targets in your MSBuild logs, you'll start seeing a matching WinFX.props now!

• WPF .NET Core application templates were missing [ThemeInfoAttribute] out of the box Regression in application template, generic.xaml doesn't work out of the box #1699.

  • This is now fixed and will become available in the 3.1 SDK.

• Sometimes, WPF projects fail to build correctly in Visual Studio, with the following error: Error: ‘CS0103 - The name ‘InitializeComponent’ does not exist in the current context. XAML intellisense file generation doesn't work in CPS projects #1915.

  • @davidwengier contributed a fix for this (Ensure that markup compilation is run for all design time builds #1895) and it will also be available in .NET Core 3.1 SDK.

• .NET Core SDK is designed to reference WPF assemblies as a set. We either reference the 'WPF', 'WinForms' or the full profile depending on the values of UseWpf and UseWindowsForms properties in a Microsoft.NET.WindowsDesktop.SDK project. In any of these configurations, all WPF assemblies are referenced together, which includes WPF's theme assemblies:

  • PresentationFramework.Aero
  • PresentationFramework.Aero2
  • PresentationFramework.AeroLite
  • PresentationFramework.Classic
  • PresentationFramework.Luna
  • PresentationFramework.Royale

  These assemblies are unusual in one particular way - they contain the same types in them (albeit with different theme resources). Referencing more than one of these assemblies would make it impractical to access the types within them programmatically - since the compiler would be unable to decide how to disambiguate between the referenced assemblies.

  See Theme assemblies cannot be referenced #765

  We worked with the SDK team to evaluate different options, but ultimately decided that directly solving this in the SDK was not within the scope of 3.0 or 3.1. We believe that the number of affected projects would be small, and they can leverage a workaround that we have proposed here

  We will continue to listen to customer feedback and revisit this in .NET 5 if we learn that our current recommendation is not meeting the needs of our customers.

Accessibility

• When applying High Contrast Black theme, button selection is not visible. (A11y_.NETCore3.0(WPF)_WPF Text Formatting_HighContrast: Button selection is not visible when we apply High contrast Black theme.  #1458)

  • @arpitmathur fixed this via Adding border to ToggleButton when checked in high-contrast themes #2092. You can see the before vs. after difference.

  • Before vs. After:

    • 
    • 

• Screen Reader read incorrect values for number of menu items, and calculate their positions incorrectly. This can result in incorrect announcements. A11y_.NETCore3.0(WPF)_WPFConcepts_MenuSample_Screenreader: Screen reader is announcing wrong ordering for the file /edit / Project menuitem  #1467

  • This was also fixed by @arpitmathur in Removing separators from SizeOfSet and PositionInSet counts #2090

WPF Samples

• We have archived the .NET Framework branch of the WPF Samples repo, and have enabled the master branch to build on .NET Core 3.0 by default.
• We have also now enabled PR builds on this repo, and worked through the backlog of PR's.
• We recently added support for the Samples Browser at https://docs.microsoft.com/samples.
  • Much thanks to Dan Delimarschi(@docs-product) for helping us through this process.
  • Most of these samples can now be discovered from https://docs.microsoft.com/en-us/samples/browse/

Over the next couple of months, the WPF team will be identifying a small set of samples that illustrate end-to-end applications, and improving them to showcase how Accessibility best-practices can be followed when building WPF apps. We hope to produce improved samples that would complement tools like Accessiblity Insights for Windows and our developer guidelines.

Open Sourcing

We haven't forgotten about the open-sourcing of native binaries.

There has been much ongoing work to vet the sources for IP, security issues etc. - and make appropriate changes before they can be published on GitHub. We have been working on it and we will share more in the next update.

Happy Holidays

Late November through early December is the start of holiday season in the US. Many of our colleagues start going on longer vacations around this time. We will be back with our next update in January when full attendance at work resumes.

Happy New Year!

The WPF Team
@dotnet/wpf-developers

[vatsan-madhavan]

Please see #2554 for the next announcement 😄

Cheers!