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 →

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).

CodeProject

C++/CLI allows you to mix native C++ code with managed .NET code (which is extremly nice). Mixing such code also allows you to create methods in a .NET class that take or return pointers to native (C++) classes. Unfortunately, this doesn’t work out of the box across assemblies (read: DLLs). If you define a .NET class in one assembly and this class has a method that returns a pointer, you may not be able to use this method from within another C++/CLI assembly.

This article describes the problem and shows solutions.

Read more →

If you have some binary files you need for your Visual Studio project but you don’t want to add them to your version control system, here’s a PowerShell script that does the downloading for you:

download.ps1

Basically this mimics a very simple dependency management.

Source Repository: https://bitbucket.org/mayastudios/powershell-downloader/

Configuration ∞

At the very top of the script, you define which files to download where.

For example, this downloads the x86 and the x64 version of a SQLite .dll file:

$base_url = 'https://mydomain.com/sqlite'
$files = @{
  '..\sqlite.dll' = "$base_url/x86/sqlite.dll"
  '..\sqlite_x64.dll' = "$base_url/x64/sqlite_x64.dll"
}

Entries must be separated by line breaks or semicolon (;).

Paths are relative to the location of the script file.

Usage ∞

To include the script in your project, call it from your project’s Pre-build event.

For example, if you’ve placed download.ps1 in a folder called libs in your project, use this line to execute it:

powershell -ExecutionPolicy ByPass -File "$(ProjectDir)\libs\download.ps1"

That’s it.

When Does It Download ∞

The script will download the files if:

• they don’t exist
• the script file is newer as the files (idea behind this: you’ve changed the file version to download)

• a file named force-download.txt exists in the scripts folder and this file contains anything else but “false”

These rules are defined in the Needs-Downloading function.

Being a C# programmer, I recently found some use for Microsoft’s PowerShell (the cmd replacement). What’s nice about PowerShell is that it has full access to the .NET framework.

However, there are also some very pit falls when coming from C# (or any related programming language).

There’s one very mean pit fall when it comes to functions and their return values that – if you don’t exactly know how PowerShell works – makes you pull out your hair.

Read more →