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!

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.

A solution to Visual Studio Tools for Docker debugging problem

I you have problems with debugging your .net core application using Visual Studio Tools for Docker - the app simply stops at start and you see a lot of Trying to connect to http://localhost (N/120) messages (where N = [1,120]) - then you might be interested in the workaround.
Which, as it turns out, is quite simple.
Open docker-compose.debug.yml file and simply remove the volumes section:
      - .:/app

Then you can debug it normally.

See the original solution post named Trying to connect to http://localhost/ (1/XXX) in Q and A section.

Fixing connection problems between Visual Studio and Mac when building iOS applications

I’ve been digging a bit into problems of connection between Visual Studio (Xamarin.iOS) and a Mac and wanted to share a few tips here.

It all started with my Visual Studio being unable to build an iOS application due to the connection issues. Basically I could connect through Xamarin Mac Agent (XMA) through Visual Studio but then the build would fail saying that it couldn’t log to target Mac given my username.

For starters one might read Connecting to the Mac and Connection Troubleshooting topics. But my problem wasn’t listed there or anywhere else. So I had to figure it out on my own.

First hint was that XMA required me to type in the username/password for connecting to the Mac. It connected and I could show the iOS simulator but I couldn’t build. When configured properly it shouldn’t ask for credentials, perhaps only for the first time. For me it was asking for credentials each time I started Visual Studio.

After reading, digging and googling I understood that XMA is using SSH tunnel to connect to the Mac. First thing was inspecting the log files (VS Help/Xamarin/Open Logs…). I didn’t find much there (other than failed connection to the host lines), or so I thought. Next thing was – checking the SSH connectivity (command prompt, ssh username@host). Using my default private key I had no problems connecting to the Mac but Visual Studio kept failing the build process. Next thing to try was Xamarin’s own SSH diagnostics app (provided as C# sources – kudos) which would throw Permission Denied (publickey) upon Connecting to host. Since the public key is on host, the problem obviously has to do with the host – but why since it was working from command prompt. Using this app I also found out what private key is XMA using. And it isn’t my default one, which I tested the connection with.

The thing is that XMA is using its own private key which you can find it at %LocalAppData%Xamarin/MonoTouch/id_rsa. So next thing I tried was connecting through command prompt/ssh using –i PATH argument (forces what key is used), i.e. (replace %LocalAppData% with value) ssh –i %LocalAppData%Xamarin/MonoTouch/id_rsa user@host. And yes, it didn’t work. So definitely a key issue.

The solution

Time for looking at Mac, specially in file /Users/username/.ssh/authorized_keys  where public keys for my profile are stored. And as anybody would guess, it was missing Xamarin’s public key. To get one from the private key I used Puttygen (a part of PuTTY): imported XMA’s private key and copy & pasted the public key portion right into the new line of authorized_keys file on Mac (I had my default public key already in there). This time the ssh command line tool connected without problems. And so did XMA from Visual Studio. Happy me.

The cause

This let me thinking, why does it usually works without intervention. After further examination of log files, it was clear. XMA first tries using its private key, if it doesn’t succeed it tries to cat the public key portion to authorized_keys file on Mac (probably using the credentials you have to enter ). But what happens if the authorized_keys file is read-only? Ha, nothing, a log entry and that’s it. This was my case, I had authorized_keys file as read only. I wouldn’t mind a clear warning: “hey dude, XMA was unable to modify your authorized_keys file, please enter this public_key manually”. It’d certainly spared me some time.

The security considerations

Let me repeat what happens when first time connecting to Mac. XMA would create a private key and put its public part into authorized_keys on Mac. Were you aware of that? No? Neither was I. To make things complicated, the private key in question isn’t password protected. Theoretically an app that user runs (no admin privileges required) could use the key (or worse, copy it through the Internet) to connect to your Mac and gain your credentials on the Mac, which are most probably administration ones. It still would have to type in password for su access, but nevertheless, this isn’t something that should be taken easily IMO.

I certainly wish that the connection mechanism was better documented and people were aware what’s going on. If nothing else, we could pinpoint the problems more easily. Also, an option to use password protected private key would be much more secure.

(Android) Emulator on Hyper-V

An apparently great news is that Microsoft has been cooking up an Android emulator. It appears that every company now feels compelled to create one. Right now we have Google’s emulator, Intel HAXM support for it, Genymotion, Xamarin Android emulator and now the Visual Studio’s one. It is getting crowded, isn’t it?

So, why I did write an apparently great news. Because the VS Android emulator, just like Windows Phone emulator, runs on top of Hyper-V. Which is not bad from the technical point of view but it is certainly not a good option on a developer machine. And that’s because turning on Hyper-V means that no other virtualization host can coexist. That’s right, forget about VMWare Workstation and Virtual Box when Hyper-V is turned on. Which makes sense on a server but on a developer machine it is sort of silly. The solution? According to Hyper-V crowd it is simple:

Just reboot with Hyper-V turned on or off, depending on your needs.

Which is … silly and really annoying. Heck, even Microsoft acknowledges this problem and it even lists it as one of the motivations beneath Visual Studio’s Emulator for Android:

Conflict with Hyper-V on Windows. Many emulators require you to disable Hyper-V or don’t work as well with Hyper-V as they do without. Using Hyper-V is part of the development setup for many developer activities, so asking you to restart your machine (multiple times a day) to toggle Hyper-V is not acceptable.

I agree that switching Hyper-V on and off is not acceptable. Bot nor is this solution. Instead of getting rid of (or modifying) Hyper-V when it comes to emulators, Microsoft decided to start creating all sort of emulators based on Hyper-V instead. Which is somehow conflicting with the awesome direction of open sourceness and multi platforms MS recently took. On the one hand they are going all nuts with open source and collaboration with other OS (amazing, btw) while on the other hand they are trying to monopolize virtualization on workstation machines. In the times when a mobile developer has to work with all sorts of different tools and software!

Other issues with the Hyper-V based emulator are that they require SLAT support (won’t run on older CPUs) and that they require Windows 8.x Pro or better. Both VMWare Workstation and Virtual Box run on “every” Windows you throw at them. Ah, and don’t forget that it will hardly support Google Play out of the box due to the Google’s silly restrictions (no emulator is allowed to ship Google Play except Google’s own).

So, the bottom line is, that yet another Android emulator is welcome, but it could be done much better. I’ll probably stick with Genymotion for the time being, since it works regardless of Hyper-V and is more feature packed that the rest.

Righthand’s DataSet Debugger Visualizer supports VS2013

Highlights from new version to 1.0.11.

  • added VS2013 version
  • added a "separated assembly" versions. Until now I was using RedGate's Smart Assembly to pack all referenced assemblies into a single DLL file for easier management and distribution. However, this black magic might cause problems in certain situations (Visual Studio add-ins screams for problems). Thus I've added another set that features assemblies in separate files. The bottom line, if you have problems or you want to be on the safe side, use the later set.

Go nuts!

Making JSON data strong typed with TypeScript and CodeSmith

The situation

Imagine a scenario where you have a JSON service that returns data and you'd like to have it strongly typed on javascript powered client side.

Let's say there is an ASP.NET MVC application that goes by the name MvcApplication33 (yes, the 33rd in a row of test applications) . There are two models in there in two files under Models folder:

namespace MvcApplication33.Models
    public class Customer
        public string Name { get; set; }
        public string Surname { get; set; }
        public int Age { get; set; }
        public Order[] Orders { get; set; }

namespace MvcApplication33.Models
    public class Order
        public double Amount { get; set; }
        public string Category { get; set; }
        public bool IsActive { get; set; }

There is also a ApiController derived CustomersController like:

namespace MvcApplication33.Controllers
    public class CustomersController: ApiController
        public IEnumerable<Customer> GetCustomers()
            return new Customer[]{ new Customer
                Name = "Tubo",
                Age = 22,
                Orders = new[]{ new Order { Amount = 54, IsActive = true, Category = "waste"} }

It simply returns an Customer array consisting of a single customer with a single order. The javascript, well jQuery, code that gets this data would look like:

$(function () {
        $.getJSON("/api/customers", null, function (d) {
            var jsonCustomer = d;

The problem

While the code above works there is a drawback (mostly for people coming from strong typed languages): on the client side there is no metadata information at design time whatsoever. One is left with dynamic constructs. TypeScript addresses this with interfaces. One could write matching TypeScript interfaces for C# types like:

interface ICustomer {
    Name: string;
    Surname: string;
    Age: number;
    Orders: IOrder[];
interface IOrder {
    Amount: number;
    Category: string;
    IsActive: bool;

and then rewrite retrieval like

$(function () {
    $.getJSON("/api/customers", null,
        d =>
            var customer = <ICustomer[]>d;

This way customer becomes an instance of a type that implements ICustomer which means properties are now strong typed and intellisense works. Of course this is only TypeScript design time sugar which doesn't reflect in generated javascript code but that's enough to prevent a zillion of typing and other "easy to catch at design time" errors.

There is one problem though. Typing interfaces is boring, error prone and there are synchronization issues between manually typed ones and their C# originals.

The solution

There is already all metadata information for our interfaces in C# code. Hence I created a CodeSmith template that automatically creates TypeScript interfaces based on their C# originals by parsing C# code. When C# code changes the template can be rećrun to recreate interfaces. Almost one click error-less operation.

Here is how it works: the template parses all C# files in a given folder and subfolders and generates matching TypeScript interfaces with corresponding namesapaces (using TypeScript modules). The template output for the given problem would look like:

// Autogenerated using CodeSmith and JsonGenerator
// © Righthand, 2013
module MvcApplication33.Models {
export interface ICustomer {
    Name: string;
    Surname: string;
    Age: number;
    Orders: IOrder[];
export interface IOrder {
    Amount: number;
    Category: string;
    IsActive: bool;

    export module Subform {
        export interface ISubclass {
            Tubo: bool;


Just for testing nested interfaces there is also interface ISubclass from original file located in Models subfolder named (Subform).


The TypeScript file that uses the mentioned autogenerated interfaces should reference autogenerated interfaces file using <reference> directive. Here is a sample TypeScript test:

/// <reference path="typings/jquery/jquery.d.ts" />
/// <reference path="../CodeSmith/JsonInterfaces.ts" />
module KnockoutTest {
    $(function () {
        $.getJSON("/api/customers", null,
            d =>
                var customers = <MvcApplication33.Models.ICustomer[]>d;

How to

The template comes in two parts. An actual CodeSmith template (JsonInterfaces.cst) and a .net assembly (KnockoutGenerator.Extractor.Parser.dll - name should give you a hint where all this is going in a next blog post) which is used to extract metadata from C# sources. The assembly code could be a part of CodeSmith template but it is easier to develop (read: debug) code within Visual Studio. The assembly in turn uses NRefactory (free C# parser and much more) which (v4.x) is a part of CodeSmith, so no additional files required.

Perhaps the easiest way to use the template is to include these two files in a project and use CodeSmith from within Visual Studio. The template requires a single property: FolderWithModels which is rather self explanatory. Excerpts from attached sample project:

The CodeSmith project content located in Project1.csp:

<?xml version="1.0" encoding="utf-8"?>
<codeSmith xmlns="http://www.codesmithtools.com/schema/csp.xsd">
    <propertySet name="JsonInterfaces" output="JsonInterfaces.ts" template="JsonInterfaces.cst">
      <property name="FolderWithModels">..\Models</property>

The project structure. I tend to put CodeSmith related stuff in CodeSmith folder. Feel free to arrange it otherwise.

folder structure

Right click on Project1.csp and Generate Outputs should (re)generate JsonInterfaces.ts. Open the output file and if Web Essentials and TypeScript are installed it should (re)generate final JavaScript file.

The project itself won't show any meaningful output (for now) but you can use JSON output in a strongly typed way.

Have fun and read next post which will talk about further enhancements for knockoutjs.

You can download my sample project (without NuGet packages, just sources) which includes everything you need (subfolder CodeSmith).

MvcApplication33.zip (566.78 kb)

NOTE: The CodeSmith template could be rewritten to T-4 (using the same support assembly) however, one should make sure that NRefactory assemblies are there otherwise parser won't work.

Righthand DataSet Visualizer goes 1.0

As a New Year’s gift I’ve fixed few bugs in Righthand DataSet Visualizer and set its version to 1.0.

Here are some changes:

  • uncompressed assembly is a bit larger due to avoiding compression within merged assembly.
  • RowState is visible again
  • some grid drawing related fixes

Read more about Righthand DataSet Visualizer here.

Download the newest and older versions from download section.

2008 version is here.

2010 version is here.