XAML Support Refresh in ReSharper 7.1

Alexander Shvedov

Just so you know, we’re continuously trying to improve the coding experience of everyone who works with XAML. ReSharper 7.0 that we have released a couple of months ago was highly focused on supporting Windows Store application development and quite frankly, didn’t contain many changes targeted at a broader crowd of XAML pros. Come 7.1, it’s time to make everyone happier, even if you’re not very much into Windows Store apps right now.

Code completion

The main challenge that we’ve solved in ReSharper 7.1 was to come up with fast, smooth and smart automatic code completion in XAML markup. Providing code completion lists in XAML is sometimes a non-trivial task: for example, WPF actually exposes hundreds of public types with lots of members like attached properties and events that should be taken into account while building completion lists. By virtue of reviewing our caching strategies in ReSharper 7.1, we ended up with a nice performance boost in code completion and whole XAML support as well.

Automatic completion by design drops many possible types that you can possibly use to qualify properties in XAML markup and includes only types that can bear a meaning in the current context:

If you’re looking for the full list of possible types with attached properties/events, just invoke symbol completion (Ctrl + Space). This behavior differs from that used in other languages where automatic completion works pretty much the same as symbol completion. However, it makes XAML lookups much cleaner and more precise in most cases. If you happen to find this behavior confusing, please vote or leave a comment under this issue.

Property completion in XAML now highlights a type’s own properties with bold, helping identify control-specific properties among thousands of those inherited from framework classes:

When generating completion lists for markup extensions, ReSharper can now filter out properties that you have already set:

An action to generate event handlers is now available with both automatic and symbol code completion:

If invoked inside an empty x:Name attribute, symbol code completion now suggests name options derived from control type name. If you’re providing a prefix for the new name, it still works as expected:

Automatic code completion is getting much more useful when dealing with resources: completion list is filtered based on expected resource type:

Field modifiers in Windows Store applications are now correctly handled and completion list now includes the previously missing protected modifier:

Different icons help identify markup extensions when using object element syntax:

Automatic closing tag code completion in all XML-based languages now only shows tags that are actually not closed:

A plethora of other small improvements has been implemented in code completion for XAML, including fixes in the calculation of expected types and improvements in Windows Workflow Foundation (WF) projects. As expected, XAML code completion in ReSharper reacts to type changes immediately, without requiring to build your project.

Typing assistance

The second important area that has been improved for XAML developers is typing assistance.
ReSharper 7.1 introduces some really nice bits of HTML editing experience to XML-based formats (including XAML, web.config, MSBuild scripts and all other kinds of XML documents) — for example, synchronous tag editing:

A feature called smart slash helps create self-closing tags by automatically removing the closing tag and placing the caret after the new tag for you (and also removing any white space that could have left between the converted pair of tags):

In order to prevent code completion from getting in your way, it should be able to detect when you’re trying to enter characters that had already been completed for you. In the case below, ReSharper auto-completes the closing angle bracket of the opening tag, as well as the entire closing tag. Meanwhile, if you’ve not looking at the screen and proceed to entering the closing angle bracket yourself, ReSharper simply merges the two brackets to prevent duplication:

Binding assistance

One of the greatest benefits of using ReSharper with XAML is static typing of data bindings. When ReSharper knows the binding source type it offers you a lot of opportunities: navigation directly to bound properties, code completion for property paths, refactoring support, error validation, and more. Static typing increases maintainability of your XAML markup, especially in applications with heavy usage of bindings (like MVVM-based apps.)

ReSharper is trying to infer the type of binding source in many ways (like in the screenshot above) but in cases where it’s not possible, there’s an easy way to annotate the data context type with design-level annotations, now using a submenu:

Such annotations are usually only required at the top level of XAML element trees. ReSharper 7.0 is trying to utilize the property name you have already typed and suggest a smart choice:

If the suggested type doesn’t fit, you can trigger import completion or enter a new type that can then be declared from usage.

ReSharper 7.1 offers new ways to infer binding source type. One popular scenario that is now supported involves binding through the DataContext property of another named control element. ReSharper can now share information about data context type between different controls:

ReSharper provides code completion and other features despite <DataContext property being of System.Object type. Similar bindings with RelativeSource mode are also supported.

If you are using custom markup extensions as binding source, ReSharper 7.1 can now calculate data context type from [MarkupExtensionReturnType] annotation in WPF (or implementation of IMarkupExtension<T> interface in Silverlight 5):

Binding type calculation also deals with CollectionViewSource in ReSharper 7.1 with respect to design-level attributes like d:DesignSource. Finally, ReSharper 7.1 introduces support for IValueConverter annotated with [ValueConversion] attribute:

Naming consistency

ReSharper 7.1 now highlights naming consistency issues in XAML markup just like in other supported languages and offers actions to fix naming. Naming rules are configurable for XAML fields, resources and namespace aliases.

Create from usage

ReSharper’s Create from usage family of quick-fixes can be very useful during development of custom controls or building custom object structures in XAML markup. ReSharper 7.1 knows a lot about all the types that you are using inside markup and improves actions like Create type and Create property with calculation of expected types — similar to how it does in C# and VB.NET:

You can specify a resource for a non-existing property, use nested object element like in the example above or even bind the property to something — ReSharper 7.1 will suggest the correct type for the new property when it creates it from your usage:

Custom bindings and resource dictionaries

ReSharper 7.1 introduces basic support for custom resource dictionaries and binding extensions. Custom structures are currently detected via naming conventions. Inheritors of ResourceDictionary type should be named using “ResourceDictionary” suffix in order to be correctly handled by ReSharper in XAML markup and participate in resource resolution:

There’s a similar story with custom bindings: you should use “Binding” suffix to enable ReSharper support for your custom markup extensions that complement XAML binding capabilities:

In future versions, we’ll be looking to provide adequate tooling without enforcing any particular naming conventions.

Other fixes

We’ve also implemented a number of miscellaneous XAML support fixes including (but not limited to) the following:

• Suppressing inspections with comment now works everywhere in XML documents (including XAML, web.config.)
• Color boxes in code completion and color usage highlightings are back in Silverlight and WinRT projects (both in XAML markup and code-behind files.)
• Unused XAML resources are no longer highlighted with gray in their entirety: only resource keys are highlighted.
• Support for markup extensions has been rewritten to solve a bunch of issues and provide improved code completion.

Here’s the full list of XAML-related fixes implemented for ReSharper 7.1 this far, and we still have quite a bit on our XAML support improvement agenda.

As usual, any feedback on your experience with ReSharper XAML support is highly appreciated! To test drive the recent changes, make sure to download a fresh ReSharper 7.1 EAP build.

Subscribe to a monthly digest curated from the .NET Tools blog:

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!