Bug of the day: Broken renaming in ReSharper

In my opinion, refactoring is the way to keep a software project clean. So, it’s good to have tools that support the refactoring process.

ReSharper is such a tool. It provides refactoring capabilities for C#/Visual Studio.

Unfortunately, the renaming code in ReSharper currently (version 7.1.1) contains a bug. This bug may prevent ReSharper from renaming all occurrences of a certain symbol.

The following code exhibits this problem:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using System;
 
public class SomeOtherClass {
  public string GetString(int col) {
    return null;
  }
}
 
public class MyClass {
  public void YouCantRenameMe() { }
 
  public void ThisFunctionBreaksTheRenaming() {
    // The following line breaks the renaming.
    SomeFunction((row) => row.GetString(0));
  }
 
  public void SomeFunction<T>(Func<SomeOtherClass, T> func) {
    YouCantRenameMe();
  }
}

If you try to rename the method YouCantRenameMe() (in line 10), ReSharper won’t rename the method call in line 18.

The problem is the code in method ThisFunctionBreaksTheRenaming() which somehow breaks the renaming process.

Update: This bug is not present in version 7.1. So, for now, I’ve downgraded to this version.

WCF: Real Easy

If you search for WCF tutorials, you’ll find a lot of elaborate examples that involve editing several files.

This tutorial is (supposed to be) different. It uses the simple most approach I could find for using WCF. It’ll only involve one file and no XML descriptors (read: app.config).

I’ll explain how to use WCF for communicating between .NET processes and how to use it for HTTP requests.

The initial code is based primarily on this nice tutorial.

Let’s get started.

Read more →

C++/CLI Cheat Sheet

This article provides a quick comparison between C++/CLI and C#. It’s meant for those who know C# (and possibly C++) and will explain which C++/CLI language construct correspond with which in C#. (I don’t know Visual Basic so I can’t add infos about this here.)

Note: This is not a complete reference but rather quick reference for those features that are (in my opinion) the most unclear.

Read more →

C# and GC.KeepAlive()

Today, while browsing some C++/CLI code, I stumbled upon several calls to GC.KeepAlive(someObj).

Immediately I thought memory leak – because I thought KeepAlive() would keep the object alive indefinitely.

Fortunately, this turned out to be wrong, though.

After reading the documentation of GC.KeepAlive() (couldn’t really figure it out), I did some decompiling and found out that GC.KeepAlive() looks like this:

1
2
3
4
[MethodImpl(MethodImplOptions.NoInlining)]
public static void KeepAlive(object obj)
{
}

It just does nothing. So what’s its purpose?

It’s there to fake an access to a variable.

Why? The .NET garbage collector may collect a variable directly after its last use – and not necessarily, contrary to common belief, at the end of the variable’s scope.

Consider this code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class SomeClass
{
  // This field is initialized somewhere 
  // in the constructor (not shown here).
  public SomeOtherClass Value;
 
  ...
}
 
...
 
void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  YetAnotherMethod();
  // obj still alive here? Possibly not.
}

The garbage collector may collect obj just after the runtime has retrieved obj.Value (line 15), i.e. before SomeOtherMethod() is even called.

Note: The exact line where obj will be marked for collection is up to the JIT compiler. The behavior describe above seems to be called “lookahead optimization”.

Usually this optimization not a problem. It becomes a problem, however, if SomeClass has a finalizer:

1
2
3
4
5
6
7
8
9
10
11
class SomeClass
{
  public SomeOtherClass Value;
 
  ~SomeClass()
  {
     // "Value" can't be used anymore 
     // after Dispose() has been called.
     this.Value.Dispose();
  }
}

So, if obj‘s finalizer is executed before SomeOtherMethod() is called, SomeOtherMethod() won’t be able to use obj.Value anymore.

To solve this problem, add GC.KeepAlive() after the call to SomeOtherMethod(), like this (line 5):

1
2
3
4
5
6
7
void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  GC.KeepAlive(obj);
  YetAnotherMethod();
}

This way, the garbage collector won’t collect obj (and thus run its finalizer) before line 5 has been reached.

Notes:

  • The implementation of the finalizer of SomeClass is flawed – as the examples in this article show. The user shouldn’t need to worry about Value being disposed too early.

    • Rule of thumb: A finalizer should only dispose the resources of its own class, not resources of some member (by calling Dispose() on members).
    • The problem with the finalizer persists if Value is an unmanaged resource/pointer that’s being passed to SomeOtherMethod(). This is always possible in C++/CLI. In C# Value could be of type IntPtr.
    • In the examples above, consider implementing and using IDisposable for SomeClass instead of GC.KeepAlive(), if you need a finalizer.
    • You still need to use GC.KeepAlive() if you can’t change the implementation of SomeClass.
  • Using GC.KeepAlive() is like using GCHandle, just more light-weight and faster.
  • GC.KeepAlive() only works because it can’t be inlined by the compiler (MethodImplOptions.NoInlining).

.NET – Array.Clear() vs. array[x] = 0 – Performance

So, yet another performance test for .NET. This time I was checking what’s the fastest way to clear an array (i.e. setting all array members to 0 or null).

The two contesters are:

  • array[x] = 0 (iterate over the array and simply set the values to 0)
  • Array.Clear()

Here are some results:

Clearing 5,000,000,000 items per test

Array.Clear() - Array size: 5 : 31.564s
Array[x] = 0  - Array size: 5 : 4.428s

Array.Clear() - Array size: 25 : 7.477s
Array[x] = 0  - Array size: 25 : 3.315s

Array.Clear() - Array size: 50 : 4.414s
Array[x] = 0  - Array size: 50 : 3.629s

Array.Clear() - Array size: 100 : 2.571s
Array[x] = 0  - Array size: 100 : 3.292s

Array.Clear() - Array size: 500 : 0.935s
Array[x] = 0  - Array size: 500 : 3.014s

Array.Clear() - Array size: 50000 : 0.621s
Array[x] = 0  - Array size: 50000 : 2.948s

In each test 5 billion int array items were cleared (that’s 20 GB). Tests was run first with a small array whose size was increased after each test run. The test were run as Release build.

As you can see:

  • For small arrays, array[x] = 0 is faster.
  • For large arrays, Array.Clear() is faster.
  • They’re about equally fast for array sizes between 50 and 100. (My guess is, somewhere around 75.)

And here’s the source code for this test:

ArrayClearTest.cs