Visual Studio 2005 and ReSharper 4 Nightly Builds

ReSharper 4 should work with Visual Studio 2005, and it will support C# 2.0 language features. If you happen to participate in our early access program, and you are using Visual Studio 2005, please note that you have to have .NET Framework 3.5 installed.

Also, we would be happy if you were reporting any features that belong to C# 3.0 but appear in Visual Studio 2005, like suggestions for lambdas or var. Please read information about our issue tracker beforehand.

Thank you.

Better Development Tools -- Building Together

Dear early adopters!

We thank you kindly for your participation in ReSharper 4 early access program. It is going to be wonderful release for everyone, because of you. This time we receive the best response ever, and we are so excited about it!

Many brave developers, who are trying ReSharper 4 early builds with Visual Studio 2008, registered in our issue tracker and provided us with detailed, specific and very important information. This is really great, because we were able to reproduce many issues that were lurking around our code base for some time now. It is very important that you registered and provide us with non-anonymous feedback: bidirectional communication is at least 16 times more effective than one way exception submitting. One sample solution which manifests the problem is 256 times better than 1024 exceptions without a comment. And it is invaluable when you submit instructions to reproduce the problem (well, at least var value = int.MaxValue).

Thank you very much, we really appreciate your effort! With that kind of feedback we receive today, I believe we can build the best release of ReSharper, ever. Everybody wants better tools, right? ;)

Sincerely Yours, Ilya.

ReSharper 4 Nightly Builds - Are You Geek Enough?

-- When ReSharper 4 will be ready?
-- It is ready when it is ready!

We in ReSharper team want to make sure that C# 3.0 language is fully supported by the product. We spend a lot of time on features and look deep into details of every language quirk. You know, compilers and language standards may have very strange relationships, sometimes very weird. Still, we want to ensure maximum pleasure developing in C# 3.0 when ReSharper is ready. And it is not ready yet.

However, due to the popular demand amongst professional developers using ReSharper and C# 3.0, we are going to open nightly builds to the public. That is, not fully fledged tool, but rather our current development bits. Which could be very well broken, buggy, hanging, slow and useless at times. We will not take any responsibility if the tool wipes out all your source code! But you have a version control system in place, don't you?

So, are you geek enough to take the pill and try ReSharper 4 early builds? Read the ReSharper 4 EAP notes before you decide!

If you feel you can survive pre-release build, you can go to ReSharper 4 Nightly Builds and download your copy of ReSharper development bits.

Good luck!

Compiler Optimizations May Be Dangerous

Consider the following code:

static class Test
{
  public static IEnumerable<int> Select<T>(this IEnumerable<T> list, Func<int, int> f)
  {
    foreach (var item in list)
      yield return f(item.GetHashCode());
  }

  public static IEnumerable<bool> Where<T>(this IEnumerable<T> list, Func<int, bool> f)
  {
    foreach (var item in list)
      yield return f(item.GetHashCode());
  }

  static void Foo(IList<string> list, IList<string> list2)
  {
    var lengths = from hashCode in list
                   where hashCode * 2 > 10
                   select hashCode;
  }
}

This code doesn't use System.Linq extensions methods to do LINQ, and instead declares own Select and Where methods, which are rather crazy. This code compiles, but what is the type of "lengths" variable? It should be IEnumerable<int>, because that is what Select method returns. But if you look at actual compilation output, it turns out that compiler decided "select hashCode" to be very simple (actually, transforms into identity lambda hashCode => hashCode). And it removes the call to Select() method. And breaks my code. One can have some hard time understanding why their code doesn't work, or even doesn't compile.

I can force compiler to call my Select() method by surrounding hashCode in select clause with parenthesis:

    var lengths = from hashCode in list
                   where hashCode * 2 > 10
                   select (hashCode);

It is not trivial to compiler anymore, and thus it emits correct code.

UPDATE: This behaviour is by design. See 7.15.2.5 Select clauses:

A query expression of the form
from x in e select v
is translated into
( e ) . Select ( x => v )
except when v is the identifier x, the translation is simply
( e )

I still find this very error prone...