Fixing CalendarDatePicker's template

[llongley]

CalendarDatePicker's default template currently references two properties added in later versions of XAML without using conditional XAML. This adds conditional XAML to the template in those cases.

[jevansaks]

While we're here, is there a way to make warnings-as-errors for the MUX solution so we don't introduce these again?

[chrisglein]

While we're here, is there a way to make warnings-as-errors for the MUX solution so we don't introduce these again?

Was this manifesting as test failures? Runtime warnings?

[llongley]

@jevansaks @chrisglein It's showing up in VS as error WMC0151. I can't seem to find any way to turn that warning into an error - the warning-as-errors directive /wennnn only appears to apply to warnings prefixed with C (which I think are C++ compiler warnings?).

Do you know if there's a way to do the same thing for XAML warnings? I'm coming up empty, and a search for "WMC warnings Visual Studio" or similar turned up absolutely nothing.

[jevansaks]

Do you know if there's a way to do the same thing for XAML warnings? I'm coming up empty, and a search for "WMC warnings Visual Studio" or similar turned up absolutely nothing.

@danzil Any ideas on this?

[danzil]

There's no such feature that I know of - that will turn XAML Warnings into Errors (when enabled). It may be possible to write an after-build targets that will look at the warnings emitted and raise an error if needed. We could also take this a feature request and create proper support for it in the Xaml Compiler targets, if there's enough interest.

[mdtauk]

Roslyn?

[llongley]

@danzil Do you have any examples for after-build targets that alter the warnings/errors reported? I didn't actually know you could do that in a target.

@mdtauk I'm not too familiar with Roslyn, but isn't it specifically for C# and VB? This is a warning returned by the XAML compiler.

[danzil]

@danzil Do you have any examples for after-build targets that alter the warnings/errors reported? I didn't actually know you could do that in a target.

I do not have an example. My recommendation was based on a purely theoretical example. I can't tell exacly how you would do that without actually trying to do it. :-)

[llongley]

@jevansaks @danzil So it turns out that there's actually an MSBuild feature as of 15.3 that I've only just now heard about, in which you can just turn an arbitrary warning into an error (or into a message), regardless of origin, instead of relying on the C++ compiler's /we syntax:

dotnet/msbuild#1928

I tested this out and this does exactly what we wanted, so I've added that to this change.