Abstract away constructor logic

I need to create an administration interface in MVC, over an old and seriously crappy DB. The fields and tables have no consistency whatsoever, but that’s easily solved through renaming things with Entity Framework. But now, I need to do 5 administration interfaces for 5 trios of tables : “master”, “images” and “categories”. They are pretty much the same, except the table and field names. To do that, let’s play with abstraction.

I’m using crude ViewModels to display my search pages. They get the elements to display in the search dropdown lists, and paginate the results. All of the logic is in the constructor (the viewmodel is only used to display a search screen). When the constructor needs to get specific elements, it calls abstract methods. They are the ones that are actually different in the various pages.

The abstract base looks like this :

And now the implementation is very simple ; here for the themes :

Theme_Combination is the joining of two entities, Master and Images. All your element_combination must inherit from IElementCombination. If they do not implement anything specific themselves, you can even use a single ElementCombination class.

Bug in WPF 4 text rendering

Microsoft has completely changed the text rendering engine from WPF 3.5 to 4.0. In the meantime, it also has introduced a bug, which you can read about here : http://stackoverflow.com/questions/23246254/ and here : https://connect.microsoft.com/VisualStudio/feedback/details/860053/wpf-4-font-rendering-bug-with-some-fonts-generated-xps-is-invalid. I have built a test project that demonstrates the problem here : https://github.com/tbroust-trepia/wpf-4-font-rendering

What looks like a small problem (the apostrophe character ” ‘ ” actually reduces the space between two characters with some fonts, resulting in overlapping characters) is problematic when you generate an XPS file from the XAML, because the resulting XPS is “corrupted”, with negative letter-spacing, which seems illegal in XPS.

I don’t really know which is to blame more : the font rendering bug, or the XPS converter (integrated in .Net !) which renders the text faithfully, but shouldn’t. Anyway, while waiting for MS to fix anything, I have found the way to fix it myself. Warning: dirty hack ahead.

Update: Microsoft has closed the ticket, and, obviously, they have decided to not resolve the issue, since it impacts such a small number of people (maybe just us ?). I always thinks it’s sad when a company this big does not close such a small and quickly-fixed bug.

WPF and MVVM discovery

In our setup, we have operations that cannot realistically be run by the installer itself, so we have a separate application that updates various components at the end of the setup. I am rewriting this app so it’s cleaner (which isn’t very difficult considering the current state), and taking this opportunity to familiarize myself with WPF and the MVVM pattern.

I am using MVVM Light, and it’s a bit of a pain. There is exactly zero official documentation. It’s a real shame, considering that it’s one of the most used MVVM frameworks. I would love to use Caliburn.Micro because it’s well documented and supported, but using it in conjunction with MahApps.Metro adds yet another layer of complexity, and I am already learning about many things at once.

Creating a responsive UI in WPF using MVVM involves many steps and components. I will need to do my work in a BackgroundWorkerautoscroll a text box, etc, and bind it in my MVVM view. What I can find here and there often lacks a few important points, but it’s generally easy to find help.

Your ViewModel needs to declare public properties for each of the things displayed in the view, that you might want to change in the ViewModel. For instance, with a progress bar, if you don’t know how many steps you will have in advance, but you don’t want to use percentages, you will need to bind the Maximum property in the VM. Opening message and confirmation boxes should be done in the view, otherwise your VM unit tests will open dialog boxes that you can’t close. To do that, you need to create a messaging system.

All in all, I still don’t like WPF/MVVM very much. It’s very verbose, and doing anything takes a huge number of steps, namespaces importing, classes, workers, commands, and messaging back and forth. I have yet to come to a point where I find that all this overhead is useful. WPF seems really powerful, but it’s also really complicated and verbose to do anything at all. The overhead of adding a screen is huge: you have to create like a thousand properties, relay commands, events and events handlers, etc. I get that it’s the right way, but it’s a really long and windy way.

The main problem I have seems to be that people come up with incredibly complicated solutions to simple problems, and then say stuff like “it is easy to do X” and “simply do Y”… after posting a hundred-lines-long post with half a dozen classes… to display a message box.

As an aside, I hate Windows XP. In addition to being incredibly buggy (most of our customer’s problems come from XP users), it prevents us from upgrading to .NET 4.5, and using shiny new toys. It’s like we’re stuck in the dark ages. We have almost 10% of our customers still using XP. It’s huge! And about 40% of them seem to never update their software version, even though they are asked to do it at each software startup. That’s a bit depressing. We can’t use the C# async/await keywords, and more and more NuGet packages require this version. I can’t even find how to display a MahApps.Metro dialog box without the async keyword.

Exploring various .NET build solutions: Albacore vs FAKE vs PSake

As I said in a previous post, I am changing our build process for our application, so I’m testing several build solutions.

FAKE is the newest and shiniest tool for .Net users. F# looks like a cross between Ruby (for the general syntax), and PowerShell (for the piping-fever-dream). Unfortunately, it seems to be missing a core piece of any proper build system: running an arbitrary exe file. I need to run the setup builder (InnoScript), but all I can find is creating a custom task, and it’s way overkill, and not very evolutive. Documentation is incredibly hard to find because of its generic name. Pro tip: do not name your software after a random generic word.

Albacore is great, running on Ruby, using Rake tasks. Installing Ruby on Windows is easy, as long as you don’t try to use some gems that won’t compile on your system. Unfortunately, Jenkins installed on Windows won’t run the ruby installed with Ruby Installer, for various reasons: PATH problems, rights problems, etc. Too bad, because my build script was working great.

PSake might be the easiest to use on a Windows build system. Documentation for PSake itself is very light, but Powershell is very well documented, very powerful, and we already use it in various places in our systems, so we know it pretty well.
The only thing I don’t like with Powershell is that, to keep things simple on one side, you have to do complicated things on the other. I don’t want to install a thousand plugins in Jenkins, so I need to build a batch “boostraper” that runs the PS scripts.

The good thing is that PSAke and Rake are very similar, so I was able to write the equivalent script in a few hours, just by putting my Rakefile and build.ps1 files side-by-side in Sublime Text.


After a year working with PSake for all of my build scripts, I can confirm that it’s awesome. Powershell is a great automation language, it’s very mature, and it has thousands of libraries and extensions.