Modularise IDE integration for better extensibility
- Dominant language
- C#
- Stars
- 7.7k
- Forks
- 1.3k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 61
Description
This is a feature request related to tooling in Visual Studio, but not exclusively and since the community hub is awful for tracking progress, I thought I'd post it here. If there's support for this, then a community hub request could be raised too.
So, there are a few parts to this, which I think are all related by the general idea...
A lot of working with WPF XAML comes down to how the IDE works, which needs to have an understanding of the code it's operating on to provide useful suggestions. For very specific things this is extensible (for example putting an enum in your markup extension), but many features seem to be hard-coded to look for Markup elements like `Binding`, and `TemplateBinding`. Because of this, creating custom markups which rely on `PropertyPath` for example aren't very useful because there's no intellisense or validation, and the only way I can see to making that work extensibly is having attributes on the `MarkupExtension` property/parameter or `DependencyProperty` to instruct how the IDE should determine what intellisense to provide or how to behave.
There are already some XAML extensibility features the codebase, for example `TypeConverterAttribute`, `ContentPropertyAttribute` and `DictionaryKeyPropertyAttribute`, however if you use the last one, it [doesn't actually get recognised](https://github.com/dotnet/wpf/issues/7562). Adding `ContentProperty` to `Setter` has been a [long-awaited change](https://github.com/dotnet/wpf/issues/84) which keeps getting undone because of backwards compatibility.
Also, some things seem to be hard-coded by the compiler and/or IDE, like how only extensions derived from `StaticExtension`, `TypeExtension`, `ResourceKeyExtension` can be used as a resource key, even though in theory any `MarkupExtension` could provide an `object` value for a key.
Similarly, although C# analysers are now very easy to add yourself, there's no official way to implement analysers for XAML.
A possible solution to both of these is 'write a visual studio extension' but that's a big ask for small teams and much easier said than done. The only one I know about is [RapidXaml](https://github.com/mrlacey/Rapid-XAML-Toolkit), and it's not yet been ported to VS 2022. The only other option is Resharper, which is extra and has its own entirely separate code inspection system.
So TLDR:
- Make IDE intellisense features for XAML rely on annotations in WPF that can also be applied to custom types.
- Make analysers for XAML (not necessarily just WPF) a first class feature to allow code and style validation (and automated fixes).
I appreciate this is a huge amount of work, and probably needs breaking down, but it would be a good to get an idea of feasibility.
Contributor guide
Assessment
This issue has not been assessed yet.