ReSharper 5.1: Bug Fixes, Performance, XAML 2009

ReSharper 5 gets its first official update today with the launch of the new ReSharper 5.1, the bug fix and performance tuning release that additionally features support for XAML 2009.

As expected, integrating with the new Visual Studio turned out to be one of the greatest challenges for ReSharper developers. It took us 2.5 months to collect feedback from 5.0 RTM and 5.1 EAP users all around the world, reproduce integration problems and other kinds of issues, fix them, and finally come up with something that we’re ready to make an official bug fix release.

If you’re still experiencing serious issues with ReSharper 5.1, please check against the Known Issues and Workarounds blog post to make sure that your problems are not related to Visual Studio itself or another external tool. If you’re still experiencing issues, you know where to find our bug tracker.

In addition to bug fixes, ReSharper 5.1 introduces support for XAML 2009 that includes highlighting and quick-fixes for language errors.

To illustrate this, let’s take a language version downgrade scenario: say you’re working on a WPF project where only XAML 2006 is allowed there but you’ve got a generic object from XAML 2009. First of all, ReSharper highlights the object as an error:

When you press Alt+Enter on the highlighting, there’s a quick-fix in the list where ReSharper suggests to declare a type inherited from System.Collections.Generic.List<string>:

When you apply the quick-fix, ReSharper makes two things. First, it creates a new .cs file where it declares a new wrapper type that inherits from List<string>:

Second, in the original XAML file, it deletes the TypeArguments attribute, changes the type of the object to the new wrapper type, and inserts a new namespace directive if necessary:

With this ReSharper 5.1 release, we’re closing the ReSharper 5.1 Early Access Program in order to focus on ReSharper 6 development. We’re really hoping that critical issues that affect multiple users are firmly behind us and we won’t have to reopen the 5.1 EAP.

David, checking exceptions you submitted, they are mostly OutOfMemory, and AgentJohnson issues. You have pretty large solution, and it looks like there are some huge xml files there. This is not something solvable in minor update, it usually requires to make architecture changes to significantly reduce memory consumption, and they are on the way for ReSharper vNext. If you have some specific exception you are referring to other than that – please tell us its number.

I’ve been using the 5 series EAP with a 250K LOC solution and it’s been working very well for me. I had to do some work to reduce the size of one of my designer files from about 22K LOC, but after that was done all was good. In fact, I’d say that the 5.0 and 5.1 EAPs have been the most stable in all R# history!

I’m working with R# since version 1.0 and it is until today a “can’t live without it” tool. But in my opinion R# 5.1 is away from being really stable too. Specially VB support is treated stepmotherly. I have, for example, reported some issues regarding the code formatter in R# 4 which aren’t solved until now altough they where addressed for release 5.1 in YouTrack. Perfomance is sometimes really slow, specially when editing large files. My wish is to release a 5.5 version with some more improvements on performance and stability and a release 6.0 with not much new functionality but even more performance and stability improvements and at least a much better VB support.

That’s great, but I’m still missing the feature for disabling automatic cleanup in XML comments in C#. Since R# 5.0 I can’t use file-wide cleanup, because it destroys our XML comments structure. It’s generally a minor drawback, but adding one switch for disabling this would be really appreciated

I’m impressed you took the time to look up the exceptions from me. Certainly the OutOfMemoryException ones are annoying, and some of those are from opening a really large solution.

This particular project is large enough that most of the time we use a separate solution with just a subset of projects – but some of those exceptions would even be from that too.

Interesting about the large xml files, as that is correct I believe there are some of those. Is there a way to tell Resharper to ignore specific .xml files (apart from excluding the file from a project)?

I’ll follow up the AgentJohnson ones and forward them to that project – didn’t realise about those.

Extended VB support is one of our priorities for R# 6, along with JavaScript and CSS. Currently we’re looking to make a more complete feature coverage for VB9 and VB10, as well as a set of VB-specific inspections.

Whether or not we’re going to release any public builds before R# 6 EAP remains to be seen – we’ll see how things are going.

maybe you should think about writing an own VB editor as Visual Studio plugin. I mostly work on C# projects, but currently have to migrate some VB6 applications to VB.NET. The VB editor has some annoying features which MS propagate as comfort functions:

- The permanent background compile decreases the performance, specially on large files and if there are many errors in the solution. Sometimes it feels like the background compile is in conflict with R# background code analysis.
- Why the hell does the compiler stops to compile after 100 errors? (i think this is “feature” of vbc.exe)
- The automatic code formatting sucks. Unfortunately R#’s VB formatting has also errors (i had entered a jira / youtrack issue a year ago on these issues, but nothing happened until now)

Beneath these issues it would be great when you can enable “Structural Find And Replace” for VB. In my current project i have to replace OCX-Controls by their .NET versions. The interface of the controls have changed dramatically. So i have to walk through the code and change the calls manually. Structural Find and replace would be a great thing to automate this annoying job.

If you can target these issues in the next R# release VB support for me will make a big step forward.

@Luedi,
Structural Search and Replace will most definitely support VB.NET
As to your other suggestions, we’ll think about them. We’ve got some ideas reg. replacing VS standard VB formatting features but no specific plans yet.

If one record in a data driven unit test is failing, I cannot see at which record the test fails. In TD I can see the value for the parameters causing the failing, in VS I can get a list of every single value.
Did I overlook this in R#?

I am using the latest 5.1 bit of R# and experience VS 2010 hangs in WPF editor mode on very small XAML files. It is getting to the point where it is a deal breaker. I can provide code and memory dumps of devenv.exe when this occurs. Let me know if you want them.