Getting HRESULT: 0x80131515 when running Righthand DataSet Visualizer?

Are you getting a HRESULT: 0x80131515 when invoking Righthand DataSet Visualizer from Visual Studio like this:


The problem is that OS marked the visualizer assembly as unsecure since it originated from the Internet. The solution to the problem is an easy one.

Locate the Righthand.DebuggerVisualizer.Dataset.2010.dll within File Explorer, right click to get Properties and click on Unblock button:

HRESULT: 0x80131515 error dialog

Happy DataSet/DataTable visualization!

What’s new in C# 4.0 presentation at NTK 2010 in Portorož

Tomorrow I am talking about new features in C# 4.0 at NT Konferenca in Portorož, Slovenia and I’ll be there through all day. So if you want to hear what features were added to C# in its latest incarnation you are welcome to attend the presentation taking place in Emerald 1, 14:45 - 16:00.

Later I’ll participate in MVP Panel in MSTech (Pečina), 16:30 - 17:30 and as a SLODUG lead I’ll be present at SloUG meeting in Sunset, 17:30 as well.

If you just want to talk about something .net-ish or just want to say hi, feel free to find me as I’ll be lurking around during my free time.

BTW, the official NT Konferenca twitter tag is #ntk10.

Righthand DataSet Visualizer now supports Visual Studio 2010

New in 0.9.16: added support for Visual Studio 2010 and updated user interface a bit. As before, everything is merged into a single dll file which is also digitally signed now.

Thanks RedGate {smartassembly} obfuscator tool for merging everything into a single DLL (ILMerge and another 3rd tool failed in this task). So far, I can only praise {smartassembly}.

Read more about Righthand DataSet Visualizer here.

Download the newest and older versions from download section.

Enjoy, and let me know whether you miss features or if you have any other feedback, good or bad.

Visual Studio 2010 and .net 4.0 are being released today

Today is the day. See Soma’s announcement and prepare your browsers pointed to MSDN Subscriber Downloads. The goods should be available for download starting at 10AM PST which translates to 19:00 for Slovenia (you might check out other local times).

Also watch the Visual Studio 2010 launch event live here.

Some useful links:

An annoying non-persistent memory leak in .net framework MDI

I had to investigate a memory leak in an application I am building for my client. It is a MDI application using DevExpress XtraTabbedMdiManager that provides some MDI eyecandy. Anyway, I’ve used ANTS Memory Profiler (an excellent profiler, highly recommended) for my mission. I have soon found the cause of the true memory leak, which wasn’t an actual memory leak but rather a feature of the application – it was logging events in the memory.

One thing puzzled me though. I’ve tried this scenario. Take a memory snapshot, open a MDI child form, close it and take another snapshot. There shouldn’t be any memory leak, should it? But it was. ANTS Memory Profiler reported that the form wasn’t disposed and still held in memory. So I went looking at the Object Retention Graph for the form in question only to see this image (sensitive namespace is removed in


Is is pretty much obvious that there are two references holding my should-be-disposed form. One is from InternalAccessibleObject and the other one is from Form.PropertyStore. Neither is caused by application’s code. So, what’s going on? It turns out that this is a feature of .net framework MDI and not a real memory leak – it stores the last reference of the active MDI child form or something like that and thus the last form isn’t released. If you repeat the open form/close step the memory leak shouldn’t increase. In fact even the memory leak from the first step is cured.

Even though it is not a true memory leak it is a distractive feature when it comes to memory profiling – for any .net memory profiler, not just ANTS. I guess only experience helps you with these kind of distractions when hunting for a real memory leak.

See also this thread in ANTS Memory Profiler support forum.

My first WPF 4.0/Windows 7 multitouch application

So I finally bought an Acer T230H multitouch enabled monitor that is supported by Windows 7. Actually, it is a dual touch but that’s enough. (for more on multitouch input devices for Windows 7 see my previous article).

On the good side it is a decent 1900x1080 monitor, not too expensive and multitouch works even under VMWare Workstation 7. On the bad side I knew it has some problems following fingers. Actually sometimes it gets just confused. That’s not a problem for a project I am working on but nevertheless I was curious.

Hence I created my first multitouch application that visualizes touch positions from monitor. Here is a screenshot featuring two fingers:


The application itself supports two different colors because I was interested only in two (no problem adding more if somebody wants me to). So, try the application and see how good or bad does your multitouch input device. Note, .net framework 4.0 RC is required.

As per my Acer T230H: indeed it has problems that usually manifest when fingers are nearby. And sometimes it just gets confused. Heck, it is one of the first multitouch monitors and a cheap one.

Have fun multitouching!

Multitouch development on Windows 7

I’ll be developing a multitouch application in WPF 4.0 running on Windows 7 and using Windows 7 native multitouch (supported in WPF 4.0) running in portrait mode. Dual finger touch should be enough. I have all the tools handy except for one: a multitouch input device aka multitouch monitor. So I am looking around for it and have found these options so far:

Bamboo Fun tablet

Last year I’ve bought a Bamboo Fun pen & touch tablet from Wacom. It supports both stylus and two finger touch input. I’ve assumed it will work natively with Windows 7. But it doesn’t. The core problem is that Bamboo has a relative touch positioning while Windows 7 requires absolute positioning – in other words Bamboo doesn’t know where your fingers are until you touch its surface. Furthermore Wacom decided to provide support through a generic driver to other OS beside Windows 7 and thus no Windows 7 native support is provided at this point in time. Disappointing.

Multitouch monitor

The most logical choice would be a multitouch enabled monitor. Heck, Windows 7 has been around for a while now (including beta and RC period) and there should be plenty of such monitors. At least that’s why I thought. Wrong again. There are some choices though. All of these supports Windows 7 native multitouch.

Acer T230H

A 23” 1920x1080 widescreen monitor from Acer. It supports dual touch through a some sort of simple mechanism using cameras. Has problems when you cross fingers or something like that. Not a huge problem in my case. But it has no pivot feature. I guess I’ll just put in horizontal portrait position on my desk or somewhere near. Despite these shortcomings this is my first choice at this point. The price tag is around 300€.

Dell SX2210T

A 21.5” 1920x1080 widescreen monitor from Dell. Smaller, slightly more expensive, dual-touch and no pivot as well.

Compaq L2105tm

The most hidden of the three. Similar to Dell’s one: 21.5” 1920x1080, no pivot. Couldn’t find it in EU so I am not sure about the price but in US is probably cheaper compared to Dell’s.

3M Multitouch developer kit

This one is interesting. A 19” 1440x900 monitor with support for up to 10 finger multi touch input. Looks like a perfect choice if it wasn’t for its price which is listed as $1.499 in US. I assume this is translated to >1.499€ for the EU. Ouch. Yet, this is the only multi-touch display that supports more than two fingers input.

Tablet PC

As an alternative to a proper monitor I might consider a tabled PC such as Dell Latitude XT2 or Acer AS5738PG-6306. First one is expensive and not exactly a development-grade fast machine, yet is a good quality product. The later is much cheaper and perhaps faster but has one fatal flaw in my case: the screen doesn’t rotate to “tablet” position and as such it won’t work in portrait mode. Furthermore touching the screen looks kind of problematic since you can easily flip it (imagine touching a standard laptop). Both laptops feature an integrated graphic card which isn’t good either.

A tablet PC is not the best option for my project anyway so I didn’t investigate much in this direction. The same goes for All-in-one multitouch PCs.

DIY alternative

Heh, I might even built a table like MS Surface by myself. Impossible? Not at all nor it is expensive. Actually it is very cheap. On the negative side it is quite time consuming, even more if you aren’t used to build such things.

Software simulation with multiple mice(MultitouchVista project)

There is way to simulate multitouch with multiple mice on normal monitor as well. Unfortunately it is not a feature of the OS but rather through a project hosted at CodePlex. Note that project has a Vista name in it, yet it runs under Windows 7 only – both x64 and x86. The idea is to trick OS to believe that mouse pointers are in reality fingers. This is done through a custom driver and a couple of services. I’ve tried to make it work with a single mouse to simulate panning and it worked on IE but not in my WPF 4.0 application for some reason. It was really a quick test and I should investigate why it isn’t working for my application further. But if I make it work this will be my way of doing multi touch until I get a proper multi touch monitor, possibly Acer T230H.


Obviously multitouch development requires either a very expensive full featured or a cheaper, but simplified and feature lacking hardware. If you don’t want to spend any money at all then you have to check the MultitouchVista project. If you are looking for a cheap dual touch monitor then Acer T230H sounds like a good choice.

Note that the hardware characteristics in this post aren’t based on real experience but rather on the data collected from internet.

If you have a different, or a better solution, or some real experience, please let me know.

Running NLog in WPF Browser Application and other partially trusted environments

NLog is a pretty slick logging library, no doubts about that. However if you try to use it from a partially trusted environment you are facing some problems. The solution is to fix two things in the sources and recompile them. Here is the recipe:

1. Open solution NLog.vs2005.sln in Visual Studio. If you have no special needs you’ll need to recompile just the project NLog.vs2005 – you can safely remove others from the solution.

2. Add [assembly: System.Security.AllowPartiallyTrustedCallers] line to AssemblyInfo.cs file. With this change you are allowing partially trusted callers. This might not be enough. See the next paragraph.

3. If you don’t provide explicit configuration then NLog will try to read from environmental variable and thus causing a SecurityException due to EnvironmentPermission request which is not granted by default. To avoid this you’ll have to comment a piece of code in the LogFactory.Configuration property:

if (_config == null)
    if (EnvironmentHelper.GetSafeEnvironmentVariable("NLOG_GLOBAL_CONFIG_FILE") != null)
        string configFile = Environment.GetEnvironmentVariable("NLOG_GLOBAL_CONFIG_FILE");
        if (File.Exists(configFile))
            InternalLogger.Debug("Attempting to load config from {0}", configFile);
            _config = new XmlLoggingConfiguration(configFile);
            InternalLogger.Warn("NLog global config file pointed by NLOG_GLOBAL_CONFIG '{0}' doesn't exist.", configFile);

Since the code is commented no EnvironmentPermission will be thrown even if there is no explicit configuration provided. As a side effect you can’t rely on default configuration settings anymore but this shouldn’t be a big issue since you can’t read them in a default partially trusted environment anyway.

4. Compile in release configuration and there you go.

Don’t forget, most of the default logging targets won’t work due to the security permissions. But the ones your application has access to will.

Happy logging.

Generic Thread.VolatileRead and Thread.VolatileWrite

I am thinking about using a generic version of Thread.VolatileRead and Thread.VolatileWrite. The code is similar to existing one (actually there are plenty of overloads) with the difference of generic type parameter:

public T VolatileRead<T>(ref T address)
    T result = address;
    return result;

public void VolatileWrite<T>(ref T address, T value)
    address = value;

Why would I use generics if there is plenty of overloads already there? Because you have to perform casting to and from object since there is a single overload that accepts reference (ref object address that is). Here is an example:

Tubo tubo = new Tubo();
object param = tubo;
Tubo read = (Tubo)Thread.VolatileRead(ref param);

Isn’t the following code much better?

Tubo tubo = new Tubo();
Tubo read = MyThread.VolatileRead(ref tubo);

The questions is whether my code is correct or not. Sure it looks like correct but one never knows for sure when dealing with threading. Feedback appreciated.

Meet “Go To Implementator” DXCore plugin for Visual Studio

The problem

One of the biggest annoyance when doing unit-test-friendly projects is that you have to deal with interfaces much more than you usually would. This isn’t bad by itself but it will effectively kill your F12 aka “Go To Definition”. In other words F12 won’t show you the code anymore but rather the interface definition of the method or property. Which is not what I like and I guess not what you like as well.

Let’s see an example:

imageWhen you F12 (or right click, Go To Definition) on DoTubo() you’ll get catapulted to the interface declaration of the method. Which might be what you want but mostly it isn’t. I’d like to see  the Tubo.DoTubo() method declaration where the code I am interested is. Specially because often an interface is really implemented just by one class, at least in design time.


This is what I’d like to see. And this is what you’d get if you weren’t using IAnnoy interface but rather Tubo type directly.

The solution

Good news is that now there is a way to use the go to method implementation. Even better news is that it is free. As a free lunch.

I’ve created a DXCore plugin named “Go To Implementator” that does exactly that. When over a interface’s method or property reference it will give you an option to go directly to (one of the) implementation. Sounds fine?


1. If you don’t have CodeRush already installed then do install its Express version which is free or even better, go with full version (which is not free but it is well worth it).

2. Download attached zip file and unpack its content into either [USER]\Documents\DevExpress\IDE Tools\Community\PlugIns or [Program files [x86]]\DevExpress [DX version, i.e. 2009.3]\IDETools\System\CodeRush\BIN\PLUGINS.

3. Run Visual Studio. Go to DevExpress/Options… menu and select IDE/Shortcuts node the left.

4. Create a new shortcut: click on the first icon under Shortcuts title. Click on Key 1 text box on the left and press F12 (you are telling which key to respond to). Pick “Go to interface implementation” command from Commands combo box. The last step is to click on checkbox Focus/Documents/Source/Code Editor on the usage tree list on right side – a green checkmark should appear. Note that you can bind this action (or any other) to a different shortcut or even a mouse shortcut or any other way supported by CodeRush.


Take also note that there is a “Parameters” text box. I’ll use it pass parameters to my action later on in the article.

Test & use

Create a console application and past in there this code:

class Program
static void Main(string[] args)
IAnnoy annoy = new Tubo();

interface IAnnoy
void DoTubo();

class Tubo : IAnnoy
public void DoTubo()

Position the caret on DoTubo() method reference. There are two ways to invoke my plugin.

Context menu

Right click, there should be an submenu “Go To Implementator” in context menu:


Keyboard shortcut (F12)

Just press F12. But what if you are not on a interface method/property reference? The default “Go To Definition” will be called like it would be without this plugin.

Dealing with more than one interface implementation

So far there was only one interface implementation. But what happens if there are two or more classes that implement the interface?

Let’s add another implementation to the crowd:

class AnotherTubo : IAnnoy
public void DoTubo()

Now both Tubo and AnotherTubo implement the IAnnoy interface. Right click context menu should give both options in no particular sort order, like this:


Let’s pick AnotherTubo class. Plugin will remember this choice and next time it will be placed on the top:


But what about F12?

If there is no default class assigned then it should present you a smart tag with options:




However, if a default is available it would go straight to the implementation rather then presenting this smart tag.

Customizing the action

Popup menu behavior is fixed and can’t be customized in current version. The action, one that you can bind to a keyboard shortcut or whatever else input CodeRush is supporting can be customized. There are two parameters (parameters are a comma delimited string that you pass to Parameters text box when you are creating/editing shortcut in DevExpress/Options… – see the 4. step in installation) you might use.


You can disable invoking Go To Definition when action doesn’t do anything. The default behavior is to pass through when action does nothing. So why would you need this option? In case you are using the action from non F12 shortcut or if you want the action to do its job and nothing else.


When there is a default class for action available no smart tag is shown by default. You can override this behavior by passing ShowPopupAlways parameter. Then smart tags menu will be shown always when there is more than one class suitable regardless the default value is present or not.

Here is an example of passing both parameters:


The conclusion

I hope you’ll find this plugin useful. I am starting to use it and it saves me a lot of clicking. And thanks to DXCore it was really easy to create it.

Let me know if you have ideas how to enhance it or anything else, all feedback is welcome.

1.0.0 (18.1.2010)

  Initial release

1.0.1 (19.1.2010)

  Bug fix: it worked only within project scope.

1.0.2 (19.1.2010)

  Too strict parsing used which might resulted in no go to implementor option at all.

1.0.3 (21.1.2010)

  Didn't work on partial classes.

1.0.4 (26.1.2010)

  Fixed navigational bug (thanks to Quan Truong Anh for finding the bug and creating a repro case)

1.0.5 (16.7.2010)

  Added some logging - make sure DevExpress/Options.../Diagnostics/Message Logs is turned on (if you are turning it on then you have to restart IDE).
  No new functionallity besides logging - you might consider this version if plugin doesn't work well and you want to understand why. (10.20 kb)


Important: this is the last version supporting DXCore/CodeRush 10.1.x and lower.

Even more important: I've created a dedicated page and all further improvements will be published throug that page. This post won't be updated anymore.