A refresh and support for Visual Studio 2019 for Righthand Dataset Debugger Visualizer

I had some spare time and decided to add support for Visual Studio 2019 to Righthand Dataset Debugger Visualizer. Along the path I decided to upgrade underlying DevExpress libraries to a more recent version and switch from Smart Assembly to ILMerge for assembly merging (the only reason is that ILMerge is open source and I wanted to test it). As a collateral I dropped support for Visual Studio 2015 and older versions. One can still use older versions of visualizers for that. The other collateral is that from now on there will be only a merged assembly version available (unless there are problems with merged ones).

So, there you have it, enjoy version 1.0.15

Switching from packages.config to PackageReference for .NET projects

Recently NuGet introduced a new way of handling packages within a project. Instead of stuffing references in a separate packages.config file, it introduced storing package references right in the project file instead.

There are several benefits (really, read the hyperlinked document) to that, the biggest one from my perspective is that it doesn't pollute NuGet packages list anymore. Previously, if you installed a package that referenced many transitive packages, then the package manager would show all of them at the same level. The worse case was when you referenced a .NET Standard package to a Xamarin application - in that case you could end up with like 20+ additional packages.

Example: adding (my favorite IoC container) Autofac to a Xamarin Android project would yield all these guys:

Not funny, eh?

So, the PackageReference way will still reference all those but it won't pollute your NuGet packages list anymore. Plus it clearly shows the top level packages under references, like this:

How does one turn on PackageReference mode?

For new projects

I suggest you set PackageReference as default mode using Tools/Options.../NuGet Package Manager window. Note that default is still package.config.

For existing projects

you should migrate packages.config file as described here. You need Visual Studio 2017 Preview 3 or newer.

That's it - no more polluted lists and many other benefits!

About in parameter modifier on value type, properties and defensive copy

in parameter modifier was introduced in C# 7.2. It lets you pass (value) types by reference but at the same time protect you against modifying the actual instance.

Here is what What's new in C# 7.2 says about it:

The in modifier on parameters, to specify that an argument is passed by reference but not modified by the called method.

Basically compiler protects you against modification of the instance in two ways:

  • when you try to change a field directly compiler will throw an error
  • when you call an instance method, compiler will create a defensive copy of the instance and run that method on the copy

But what happens when calling instance properties? Will compiler create a defensive copy as well? Even for autoimplemented getters? That's the question I've got on my presentation and I wasn't sure about it. On one hand properties in general can implement modification code and in that sense they aren't safe just like methods aren't. On the other hand autoimplemented getters don't implement any modification code.

If I had to guess I'd say there is no need for defensive copies when dealing with autoimplemented getters, while in other cases compiler will resort to defensive copies.

After few experiments and using Reflector to inspect the generated code it turns out that compiler will use defensive copies with properties always, even with autoimplemented getters. You can also check it out with SharpLab.io, which is a great way into digging into (experimental) C#.

Looks like there is some room for improvement.

Troubleshooting Live Unit Test build failure

It happens that I have a .NET 4.6.2 solution including Unit Test projects that builds just fine. However, when starting Live Unit Test it would complain build completed (failed) for some reason. Which is weird since the solution builds fine.

I started searching for the reason of this mysterious build failure. First thing to do is to enable verbose Live Unit Test logging: Tools/Options.../Live Unit Testing -> Logging Level. Once set to verbose it become obvious that Live Unit Test BuildManager had problems with some referenced third party assemblies, specifically (in my case) with NUnit and Moq. Errors were like this:

[09:02:50.728 Verbose] - BuildManager - MY_TEST_PROJECT_PATH\SomeFile.cs(1,7): error CS0246: The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)

But why wouldn't it find these Assemblies where VS has no problem finding them. Note: I added these two (and other) assemblies through NuGet.
I went looking where the problematic references actually point (Solution Explorer, Test Project, References) and saw something odd. Instead of pointing to a some path under NuGet Packages directory they were pointing to build output directory. At some point in the past VS decided that it has to change the path to the assemblies for some reason. Probably it couldn't find them at original location and decided to find the only ones it could - ones from the recent build in the build output directory. Which is a bad move from Visual Studio and one that most certainly causes problems.

At the end the solution was rather easy once I discovered the reason. I simply upgraded NuGet packages to a newer version. Reinstall would also work.

More about SharpRedux

Since last post about SharpRedux I added GettingStarted sample, did a bit of refactoring and added quite some documentation.

Go check the documentation and play with both samples.

Next step is to create a centralized hub for pushing actions and reading from into a visulizer. This will make visualizer and development of (mobile) apps much better experience. Also collecting history from apps running in the wild. Stay tunned.

Quick introduction to Righthand.SharpRedux library

I've been experimenting with a redux implementation for .net lately and here is the current state.

The core library is quite functional and ready for a bit more serious test drive. There is also a visualizer, redux based, and with a frontend for WPF (other frontends can be added).

Available are two sample apps, Todo which is a WPF/MVVM/redux implementation of TodoMVC. And a dirty Playground sample.

Here are two screenshots from Todo sample and a brief introduction:

The application itself is on the left while visualizer is on the right. Visualizer is further composed of actions list and state|difference display. Above it shows current state after highlighted action. Value "[0] 1" in visualizer means list item with index 0 (when a list member) and item has an unique key with value 1 (when applicable).

Above the visualizer is showing state difference between the last action and previous one. You can also select any action from the list and click Reset to State which would rewind the state to one after that action.

But why would anybody bother with redux at all? The answer is logging, separation, unit testing and state rewind. Imagine you have an application that crashes - getting all the actions in proper order would give you the ability to reply exactly what user/application was doing until it crashed - even without any user intervention or feedback.

That's it for a quick introduction. I'll try to blog more, create more documentation about it, based also on feedback/interest. I'll try using it in a real project when an occasion appears. Also visualizer can be and probably will be improved. Right now is something that works well enough for start.

Righthand.SharpRedux is open source and hosted on github and libraries will appear soon on NuGet. You can also get the Todo sample as a zip (.net 4.6.2 required),

Immutable types are based on Righthand.Immutable which is also hosted on NuGet. Visual Studio 2017 extension that creates immutable code is available at Marketplace. Righthand.Immutable is optional for SharpRedux and can be used standalone.

Mono, Docker, 3.14, WebAPI on NTK 2016

This year I’ll be presenting at Microsoft’s NT Konferenca as I do every year.

As the topic I’ve picked my experience of using Docker I gathered from a real world example. I’ve been building an application that is a combination of PostgreSQL database, Mono/NGINX/WebAPI on server and UWP/Windows10 on client. Server side supports various OS. Target is Linux but it should run on Windows without issues. The combination of server OS and server tools choice drives costs down significantly on one hand and makes it versatile on the other.

Docker helps a lot through the development and final deployment in production. And that’s what talk is all about. 3.14 will play a role as well – showing that there is almost no HW restriction for such a combination on server side. We’ll build and deploy the application through rich demos.

See you there, Monday at 9:00.

Porting a .net application to Linux/Mono/MonoDevelop

I have a small .net application that I wanted to run on Linux since it is a deamon/service sort of app. Basically is an app that peridically retrieves data from a REST service and stores it to a PostgreSQL database using LLBLGenPro 5.0 CTP2. So I created a .net 4.6.1 console application that uses HttpClient/ModernHttpClient package, NLog package for logging and System.Collections.Immutable package for immutable collecitons obviously. That was on Windows using Visual Studio 2015. After I added all the necessary code it run perfectly well on Windows.

Then I tried to open the same solution on Linux. I cloned the repository and opened it in MonoDevelop 5.10/Mono 4.2.1 (both latest). And it didn’t work out of the box. I stumbled over several issues I will describe here.

.net version

MonoDevelop doesn’t work with anything over .net 4.5 for the time being due to the MSBuild thing – at least that was the complaint.

Hence I downgraded my project to .net 4.5. No problems since I didn’t use anything .net 4.6ish.


It won’t install System.Collection.Immutable package because System.Linq package (which System.Collection.Immutable depends on for some reason) won’t install unless NuGet Package Manager is 3.0 or newer. MonoDevelop uses NuGet Package Manager 2.8.7. While this is only a NuGet Package installation issue, it is annoying. First, because System.Collection.Immutable doesn’t really require System.Linq package on Mono/.net 4.5 and next becuse it isn’t smooth as it should be. Funny thing is that at NuGet web page it says that System.Collection.Immutable requires NuGet 2.8.6 or higher. I guess it should be 3.0 or higher since a package that it depends on requires it.

Hence I dropped System.Collection.Immutable package which wasn’t difficult because I wasn’t using it extensively. Hopefully MonoDevelop catches up with NuGet and that is fixed.


ModernHttpClient speeds up communication since it uses native networking libraries. However it won’t work on Linux.

Dropped it since it doesn’t affect the functionallity at all.


I had configure NLog though nlog.config file. And it works on Windows perfectly. Hower when run on Linux I didn’t get any output whatsoever. Just like there was no configuration file. As a Windows guy I was a bit puzzled why. Since NLog is open source, I downloaded the code and tried debugging. Sadly MonoDevelop didn’t allow me to step into NLog code for some reason but luckily old school “Console.WriteLine” approach worked as usual. After some strategically placed Console.WriteLine calls within NLog library I found the reason, which might be apparent to a Linux guy. Bloody file name casing. I was using nlog.config and Windows doesn’t care about file name casing.

On Linux file name casing does and thus changing the name to NLog.config did the trick.

Linux specific addition

If app wants to gracefully handle SIGTERM signal (like when somebody/something tries to kill it) it might use UnixSignalWaiter NuGet package. While only at version 0.0.1 it seems to work just fine. It is also safe to use it on non-Linux systems where it does nothing (one might also check whether the feature is supported).


If .NET Core has proper database support (PostgreSQL in my case, but more more importantly LLBLGenPro doesn’t work due to lack of ado.net support – I don’t know about you but for me the proper ado.net stack on server is one of the most important aspects) I’d try to use it as well. But since it doesn’t, well, someday in the future I guess.

Anyway, after learning all the problems and the workarounds above I feel more confident in my Mono/Linux skills and the application compiles fine and works as expected. I also think that Xamarin/mono guys are doing really great job. Kudos.

Did I mention that I’m using Docker to run the application? I guess that’s a topic for a future post.

TwoWay binding trap on Windows Store apps

Imagine having a TextBox bound to a viewmodel’s property in a TwoWay mode. In between a converter that does possibly an asymmetric conversion – in this case the text is uppercased (it should do for this demo).

Like this:

        <local:UppercaseConverter x:Key="cnv" />
    <TextBox Text="{Binding Text, Mode=TwoWay, Converter={StaticResource cnv}}" Margin="0,60,0,0" />
    <TextBlock Text="{Binding Text, Mode=OneWay}" />
    <Button Content="Test" Click="Button_Click" />

Below is an additional TextBlock for feedback and a button that assigns a value to the property bound.Here is the WPF converter (Windows Store version has a slightly different method signature)

public class UppercaseConverter : IValueConverter
    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        if (value == null)
            return null;
            return ((string)value).ToUpper();

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        return value;

and the viewmodel with a single property and INPC implementation:

public class Tubo : INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    private string text;
    public string Text
            return text;
            if (text != value)
                text = value;

    protected virtual void OnPropertyChanged(string name)
        if (PropertyChanged != null)
                new  PropertyChangedEventArgs(name));

Finally the code behind the XAML page:

public partial class MainWindow : Window
    private Tubo source;
    public MainWindow()
        source = new Tubo();
        DataContext = source;

    private void Button_Click(object sender, RoutedEventArgs e)
        source.Text = "Tubo";
Everything is pretty much straightforward. The instance of Tubo is created and assigned as DataContext. On button click a value is assigned to Tubo’s Text property. Binding picks up the PropertyChanged notifications and displays the UppercaseConverter converted value in TextBox and a raw value in TextBlock.

Now the question. What will be the two values displayed in a WPF application and in a Windows Store application after pressing the Test button? Can you guess?

I’d expect TUBO (uppercased) in TextBox and tubo in TextBlock since there is no conversion applied and user didn’t change anything.

And that’s the case with the WPF application. But the surprise result comes from Windows Store application. It shows both values as uppercased. It gets even worse, this behavior isn’t consistent, more on this later.

What actually happens is that Windows Store app (who invented that name anyway) TwoWay binding does both directions on value change: it picks the modified value from viewmodel and immediately stores it back into viewmodel. So without any user intervention the uppercased value is stored in viewmodel. Nasty I’d say.

But it gets worse. This behavior is only for visible UIElements. In other words, if the TextBox isn’t visible (Collapsed) at property change time it will act like expected, just pick the value from viewmodel but it won’t write it back to viewmodel.

The combination of both might result in edge case bugs one would really not expect and might not be caught easily.

Luckily there is a workaround. The source updating has to be done manually by

  1. Setting Binding’s UpdateSourceTrigger=Explicit
  2. Implementing own logic when to update the source (this might be tricky)

Here is how one does update the source in an overriden TextBox (better to create a Behavior though).

BindingExpression be = GetBindingExpression(TextProperty);
if (be != null)

NCrunch and SQLite testing problem and solution

I have some NUnit tests on .net 4.5.1 class library against PCL and both use SQLite.Net PCL, the former uses its Win32 platform.
When running from a test runner (like CodeRush Unit Test Runner) it works just fine.
But NCrunch would throw an exception when trying to create a SQLiteConnection instance:

            path = Path.GetTempFileName();
            connection = new SQLiteConnection(new SQLitePlatformWin32(), path);  // exception thrown here

SetUp : System.TypeInitializationException : The type initializer for 'SQLite.Net.Platform.Win32.SQLiteApiWin32Internal' threw an exception.
  ----> System.Exception : Failed to load native sqlite library

I've found out that this behavior is due to the missing Interop assemblies that aren't copied by NCrunch by default (x64 and x86 folder in bin\Debug folder) to optimize the unit testing process.

Hence adding these two folders to "Additional files to include" NCrunch project configuration property does the trick - that way NCrunch will include the missing assemblies.

Find more info about troubleshooting missing files when NCrunching here.