Monthly Archives: May 2013

Shuffle a List

Given a list, how can one randomly shuffle it? Like so:

private static IEnumerable<T> ShuffleList<T>(IList<T> list) {
  var length = list.Count;

  var random = new RNGCryptoServiceProvider();
  var data = new byte[length];
  random.GetBytes(data);

  var numbers = Enumerable.Range(0, length).ToList();
  var shuffledIndices = numbers.OrderBy(x => data[x]).ToArray();

  foreach (var index in shuffledIndices) {
    yield return list[index];
  }
}

Note the use of RNGCryptoServiceProvider rather than using the Random class, which makes this code much more complicated due to the lack of a Next() method. However, it is cryptographically more sound.
Also, note the Range method of Enumerable to generate a sequence of numbers, which is a function I’m often needing and always forgetting exists (like std::iota in C++).

Strong signing of compiled assemblies

I decided I’d finally start finishing my projects properly by signing them before deployment. Everything I make (to date) has been for internal use only, so my lack of signing thus far has been of no consequence. Still, I thought I’d try to learn something – how hard could it be? You just enable code signing in your project and compile, right? Possibly.

My issues came two-fold: firstly, I made use of a referenced to three other DLLs, internally developed, but not by me. These were not strongly signed and so I could not sign my own project. Lowest common denominator. Browsing the web, I found this article. The basic premise is: decompile the DLL (which everybody knows is super simple in .NET) and then recompile, but with a strong name (i.e. signed).

I couldn’t get the key created by Visual Studio to work with this process so, as mentioned in the article, I created a new one with a different format:

sn.exe -k SigningKey.snk

Decompile your DLL into intermediate language (this also creates a resource file):

ilDasm.exe Some.dll /out:Some.il

Recompile, with a strong name:

ilAsm.exe Some.il /dll /resource=Some.res /key=SigningKey.snk

ZOMG – This works! At least, it did until I tried to run my application, at which point it crashed trying to load one of the DLLs.

The second problem I had was that one of my references also referenced another, so I had to also update the internal reference of the DLL to use the strongly-signed version of the other. I poked around in the generated IL and looked at that of other libraries referencing strongly named assemblies. And I copied that.

One needs to add a .publickeytoken attribute to the relevant .assembly section, like so (with the correct Public Key Token):

.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
  .ver 2:0:0:0
}

Et voilĂ . Everything runs nicely.

As a final note, and much simpler to resolve, in order for a test project to access internal methods of a strongly-named assembly, you need to sign the test assembly and then specify its Public Key in the InternalsVisibleTo attribute. You can grab this as follows:

sn.exe -p SigningKey.snk SigningKey.PublicKey
sn.exe -tp SigningKey.PublicKey

The attribute becomes:

[assembly: InternalsVisibleTo(
  "Project.Test, PublicKey=<really_long_hex_string>")]

via Brenton House’s Blog @ weblogs.asp.net