Tracking issue for all possible XAML compiler warnings

[maxkatz6]

• Obsolete warnings
• Deprecated/Experimental attributes warnings
• IStyle instance added to the MergedDictionaries (should be added to the Styles collection)
• Duplicate setters
• Possible null reference exception when adding Transition to the Transitions collection without initializing the collection first (Can't use transition; 'Object reference not set to an instance of an object.' #5899). Probably extend it to other nullable collections?
• Hardcoded strings that can be localized (todo: find reliable way to detect them) - disabled by default.
• Hardcoded colors that can be made theme depended - disabled by default.
• TemplatePart XAML diagnostics #14180
• Warn, if OnPlatform/OnFormFactor extension is used without default value, but in collection that requires non-null value Avoid ANE when using OnFormFactor inside Panel #14410
• XAML and C# type mismatch - Wrong base class in axaml code-behind causes internal compiler error in xaml compiler #16755. XAML ReactiveUserControl and C# UserControl - warning, but other way XAML UserControl and C# ReactiveUserControl - should be allowed.
• <DynamicResource x:Key="" ResourceKey="" /> usage in res.dictionaries. It won't work just like StaticResource.

Any other ideas?

[MrJul]

Duplicate property, two cases:

Attribute + element:

<Border Background="Blue">
  <Border.Background>Red</Border.Background>
</Border>

Double elements:

<Border>
  <Border.Background>Blue</Border.Background>
  <Border.Background>Red</Border.Background>
</Border>

Double attributes is already a XML parsing error.

[MrJul]

Possible null reference exception when adding Transition to the Transitions collection without initializing the collection first

It would be nice to have dependency properties able to instantiate collections lazily instead so users don't have to know whether they should instantiate the collection or not.

Currently we have two types:

• Always null, e.g. the mentioned Animatable.Transitions. Pain: the user must always set the collection, or it's an exception.
• Always instantiated, e.g. TextBlock.Inlines. Pain: allocation if unused (most textblocks), double allocations if set in XAML.

I'll open a separate proposal to discuss that.

[MrJul]

TemplateBinding used outside of templates. I think I see this one in discussions or Telegram at least once a week :)

[timunie]

Used ContentPresenter and friends outside ControlTeplate, which is forbidden.

[stevemonaco]

Opt-in warnings for {ReflectionBinding} usage so devs writing AOT apps can enforce avoiding its usage.

[maxkatz6]

Upd: Fixed by #18132

XAML compiled should detect following patterns:

<TabControl>
    <TabControl.ItemTemplate>
          <DataTempalte>
                 <TabItem Header="{Binding Title}" /> <!-- WARNING:  -->

And recommend something like this (possibly, just a link to the documentation/samples):

<TabControl ItemsSource="{Binding ...}">
  <TabControl.Styles>
    <Style Selector="TabItem">
      <Setter Property="Header" Value="{Binding Title}"/>
    </Style>
  </TabControl.Styles>
</TabControl>

[Al-Dyachkov]

Is it possible to add a warning when base type declaration in XAML and code behind does not match ?
Common error when a person creates UserControl via template, changes it to ReactiveUserControl and does not immediately modify the code behind to match.

[maxkatz6]

@Al-Dyachkov can you bring some example? If types of XAML and code behind are not compatible, there should already be an error (not even a warning). Unless I am missing something.

ReactiveUserControl in code behind and UserControl in XAML should also be fine.

[Al-Dyachkov]

@maxkatz6

xaml

<reactiveUi:ReactiveUserControl x:TypeArguments="VM" 
                                x:Class="View"
                                x:DataType="VM">
...
</reactiveUi:ReactiveUserControl>

code behind

public partial class View : UserControl
{ 
}

This compiles and even works to some extent because ReactiveUserControl<T> is derived from UserControl, but without Reactive UI features like activation, because it is actually a UserControl. This is a minor issue that is usually fixed right away but would be nice to have a warning anyway.

[workgroupengineering]

What do you think about pinning this issue so it's easy to find?

[workgroupengineering]

I would suggest adding a warning when a DynamicResource is reassigned. I wasted a whole day troubleshooting a problem due to this.