memory.Refresh()

I recently attended DDD North 7 in Bradford. I’ve been wanting to take up sketchnoting for a while now, but have never gotten round to doing it, so when Ian Johnson (go check out his sketchnotes - they are great) prompted me to take my sketchbook and pens with me, I reluctantly obliged. I’m so glad I did though as I really enjoyed doing them, and I feel it had the effect of me being able to recall much more of the content of each talk. I tweeted the sketchnotes after each session and got a great response from both the speakers and attendees.

Here are the sketchnotes I did during the day.

Microservices: What I’ve Learned After A Year Of Building A System

by Nathan Gloyn

Spot The Difference: Automating Visual Regression Testing

by Viv Richards

Married To The Mob (Programming)

by Derek Graham

How To Parse A File

by Matt Ellis

Alexa, Open Sneezaroo…

by Zinat Wali

If you do any kind of globalisation in your applications, you will probably already be familiar with the Thread.CurrentCulture and Thread.CurrentUICulture properties that can be used to set a culture on the thread so that .Net knows to load the correct resources and to format numbers and dates properly.

A big downside to using approach this is that the culture is only set on the current thread, meaning that any new threads created will be using the default culture for the application (which is tied to the regional settings of the operation system). This wasn’t too much of a problem years ago when multi-threading was not used widely, but in modern application development it is virtually impossible to avoid using multiple threads (e.g. Task Parallel Library), especially when trying to make use of modern multi-core hardware. You would have to manually set the culture when spawning new threads to ensure that the correct culture was being used - a real pain and a common cause of bugs.

.Net 4.5 comes to the rescue with the introduction of two new properties:

CultureInfo.DefaultThreadCurrentCulture
CultureInfo.DefaultThreadCurrentUICulture

A culture can be set using properties that will then be used for all threads in the whole application domain, meaning that you can set the correct culture at application start up and all threads will use that culture. By default, these properties are set to null meaning that the pre-4.5 behaviour will still hold and that the system culture will be used by default.

The MSDN docs for CultureInfo.DefaultThreadCurrentCulture and CultureInfo.DefaultThreadCurrentUICulture provide more details.

RedGate recently announced that from the next version of Reflector (v7), they will charge $35 for a licence. Since the announcement a few weeks ago, there has been quite a backlash against the decision from the .Net community, mainly because RedGate have put a time-bomb in the currently-free version so that it will expire at the end of May 2011. In response to this announcement, several alternatives to Reflector have surfaced - some free, some commercial. The list below outlines all of the alternatives, some of which have been around for many years.

• JetBrains ReSharper (commercial + free)
  Within a day of the announcement, JetBrains put out a teaser suggesting that a decompiler was in the works. Two weeks later, they announced that the next version of ReSharper will have an integrated decompiler akin to reflector, along with a free standalone version to be released later in the year.

• Telerik JustCode (commercial)
  Just as JetBrains put out a teaser, Telerik followed suit and showed a decompilation feature that will be in the next version of their JustCode tool.

• ldasm (free)
  This tool comes bundled with the Windows SDK Tools (that get installed as part of Visual Studio). It is purely an IL disassembler, and so cannot decompile to C#.

• ILSpy (free)
  The team behind SharpDevelop have been working hard on ILSpy and have already released a major milestone of v1 of their decompiler. It can decompile to C#.

• Cecil Studio (free)
  This is a Windows forms UI based on the Mono Cecil library. It has already been around for a few years.

• MonoReflector (free)
  This is a WPF UI based on the Mono Cecil library.

• MonoDevelop Assembly Browser (free)
  Released for the first time in version 2.0 of MonoDevelop (currently at v2.4.2).

• Salamander .Net Decompiler (commercial)
  This is part of a larger tool called .Net Explorer.

• Dis# (commercial)
  This tool has been around for a while, but is not often mentioned. It is not as polished as Reflector and does not support never versions of .Net, but has some nice features not seen anywhere else. Once such feature is to rename the decompiled variables within the tool to give them a more meaningful name.

• Spices .Net Decompiler (commercial)
  As well as decompiling to IL, C#, J#, C++ and Delphi.Net, this tool has a feature to build code flow diagrams from the decompiled source to show the execution flow.

• Decompiler.NET (commercial)
  This is s decompiler combined with an obfuscator, language translator and refactoring tool that integrates with Visual Studio.

• Keep Decompiling Free
  This website popped up recently with nothing more than a teaser to get more information when it is available.

• RedGate Reflector (commercial)
  Of course, there is still the current king of them all, albeit in a now charged-for format. Still well worth the $35.

Which of these will turn out to be the best/most successful to take Reflector’s throne is yet to play out, but there seems to be a healthy interest from both the community and commercial aspects in making a replacement.

I am currently learning F# and am starting to amass a selection of useful links. I though it would be handy to collate them all in the one place:

MSDN

• Core Library Reference
• Collections Namespace
• Collections.Seq Module
• Collections.List Module

C# and F# Equivalents

• Writing Equivalent LINQ Expressions In F#
• Mapping LINQ To F#
• What Does This C# Look Like In F#

General F#

• hubFS
• F# Cheat Sheet
• A Taste Of F# Today - Don Syme (Presentation)
• The Future Of The F# Language

I have ReSharper installed and think it is a great tool for productivity, but occasionally I find it useful to temporarily disable it to speed up Visual Studio (especially so on my old, slow laptop). This is achieved in two different ways, depending on the version of ReSharper.

In versions prior to version 5, ReSharper appears in the Add-in Manager dialog, accessed via the Tools menu. Using this dialog, you can uncheck the ReSharper add-in which will suspend it (the menu will still be visible, but its functionality will be disabled).

Checking it again will re-enable it. Both of these actions can be performed without restarting Visual Studio.

In version 5, ReSharper no longer appears in the add-ins dialog. At first glance, I though the ability to disable ReSharper was no longer available. As it turns out, it is now part of ReSharper itself and is accessed via the Tools -> Options -> ReSharper -> General dialog. Clicking the suspend button will suspend ReSharper and disable its functionality. Once suspended, clicking the resume button will re-enable it.

This applies to all versions of Visual Studio - the difference is based on the version of ReSharper only.