Discovering open source WPF components – Orc.Analytics

In the discovering open source WPF components series, I will look into useful open source components that can be used to create WPF apps. This weeks component is Orc.Analytics.

Analytics can be very helpful to analyze what features are being used the most. This information can be used when prioritizing new features or bug reports. Adding analytics to a WPF application can be cumbersome, but thanks to Orc.Analytics this is very easy to accomplish in a few steps:

  1. Create a Google Analytics ID
  2. Customize the service using this code:

Automatically sending data

Thanks to the auditing functionality in Catel, the library will automatically send data when one of the following events occur:

  • Command executed
  • ViewModel created
  • ViewModel closed (because it stores the timings / view model, it will also submit the lifetime of a view model so you can analyze how long a user is on a specific view)

Manually sending data

The library also allows you to manually send data for the following possible analytics events:

  • View (SendViewAsync method)
  • Event (SendEventAsync method)
  • Transaction (SendTransactionAsync method)
  • Timing (SendTimingAsync method)

Manually tracking views

Maybe not all the views have a view model. It is still possible to track these views by using the TrackViewForAnalyticsAsync extension method:

Viewing and analyzing the data

Once all the users are submitting the data (ask them for permission first!), then you can start analyzing your data using Google Analytics:


Developing enterprise WPF apps – a list of very useful components

At the company I work for, we write lots of enterprise apps using WPF. The base for all of the apps started by using Catel, but we immediately felt we had to fill a lot of gaps. To prevent Catel becoming an unmanageable beast, we decided to create a second group of open source components under the Orc.* branding.

This week, we finally put all the components into their first stable release, meaning we think they are usable in production for WPF apps. This blog post will introduce all the components we have at the moment with a short description. Each component has a description on the corresponding GitHub page as well with examples.

Some history

The idea behind the Orc branding is to have a basic shell (Orchestra) that people can use to get up and running very quickly. You can pick your shell (for example, using a ribbon with Fluent.Ribbon) and start working on your actual application logic instead of the application boilerplate code.

The major advantage for you is that we use these components in over 10 applications. This means very active development (nearly daily updates to the components). We are also trying to make all components have the same look and feel to it really works as a component suite.

The components

The list of components is long, therefore I have chosen to create a table instead of a detailed summary of each component. In upcoming blog posts I plan to highlight more features and details of specific components.

Component name Description
Orc.Analytics Makes it very easy to integration Google Analytics with Catel projects.
Orc.AutomaticSupport Allows the user to easily download a remote file that will validate and provide automatic support to the end-user.
Orc.CommandLine Command line parsing with an easy context class and automatic help system.
Orc.Controls WPF controls like DatePicker, DateTimePicker, TimeSpanPicker, LogViewer, WatermarkTextBox and much more…
Orc.CrashReporting Catch unhandled exceptions and automatically gather information to submit for the end-user as crash reports.
Orc.CsvHelper Small library of extensions and helper methods for the CsvHelper library.
Orc.Feedback Allows developers to easily get feedback from the end-user.
Orc.FilterBuilder Adds complex filtering functionalities to your application. A user can create custom (dynamic) filters in a visual way and store them. Very nice component to allow a user to create filters of collections.
Orc.LicenseManager Check software licenses. Consists of client and server (example) code. Uses Portable.Licensing under the hood.
Orc.LogViewer If the LogViewer in Orc.Controls is too basic for you, this component expands that control by adding filtering and much more features.
Orc.Metadata Provides base classes to store metadata about objects. This can be useful for a lot of information about objects. Might seem abstract, but this prevents you from repeating the same code over and over again.
Orc.Notifications Show desktop notifications to the user with the ability to add commands to the notifications. In a few lines of code you have beautiful notifications in your app.
Orc.NuGetExplorer A custom NuGet explorer. We use this because plugins of our applications are deployed via NuGet. This component allows the users to install and update their plugins.
Orc.ProjectManagement Manage files and projects inside your application. Instead of messing around with lots of handlers and events, this library manages projects for you (can be a file, directory, database, really anything). Other components can subscribe to this if they are interested. Are you writing document-focused apps? You really want this one.
Orc.Search If you need search in your apps, this is the component to use. It can automatically index objects for you (in the background). Provides events to notify you when objects are being indexed or searched for. super fast searching thanks for which is being used under the hood.
Orc.Squirrel Wrapper around Squirrel (the new but better click-once). This library allows you to set up channels (like alpha, beta and stable) and manages the complex stuff under the hood.
Orc.SupportPackage Allows an end-user to create a support package with the right information for you to analyse issues. Because this component is plugin based, you can gather any information you need. The info will automatically be added to a zip file which the user can export and submit.
Orc.SystemInfo Ever needed system info of the end-user? This component gathers all the information. Also used by other components such as Orc.CrashReporting and Orc.SupportPackage.
Orc.WorkspaceManagement Workspaces are a combination of settings that represent the state of the UI. For example, if you want to allow your end-users to customize UI and store the customizations, workspaces is the solution. It also contains a workspace switcher so users can easily switch between workspaces. Since this component is plugin based, it can really be used for anything (from grids to ribbons to docking solutions, etc).
Orchestra Orchestra is a composable shell built on top of Catel. There are several shells like Fluent.Ribbon and MahApps. But Orchestra provides much more features like remappable keyboard shortcuts, splash screen, about window, consistent styling of your apps and much more.

Giving NDepend a spin on Catel

One of the good things of developing Catel is that it grows so fast that the team has to make sure everything is done as professional as can be. This means that we use a lot of professional tools such as FinalBuilder (automatic deployments), Jira (issue tracker) and Confluence (docs). We also use FxCop and ReSharper for code analysis, but now it’s time to test drive another tool that looks very promising: NDepend.

NDepend will have a challenge analyzing Catel because at the moment of writing, Catel consists of 55 projects with different target frameworks (NET40, NET45, SL4, SL5, WP7, WP8 and WinRT). Let’s take NDepend for a spin!

First impression: creating the project

When starting NDepend, the first thing I noticed was that I could actually load projects that I recently opened with Visual Studio. This is a neat feature because you probably need NDepend for projects you are currently working on. It seems though that NDepend cannot load the Catel solution because we use the same output name for different target frameworks. This means that the Catel.Core assembly lives in the NET40, NET45, SL4, etc output directories.

NDepend to the rescue. We can also add .NET assemblies in a specific folder or even handpick the assemblies. Since most assemblies are the same, I will only select the NET40 output directory (NET40 is our main development project, and we link other files in other projects to this project). NDepend correctly finds the right assemblies. The only thing that they might make optional is to ignore all *.resources.dll assemblies, I am not interested in analyzing these. Now we have a very nice set of Catel assemblies:


Analyzing the dependencies

After NDepend has done it’s magic, we are now presented by a very nice dependency graph:


The nice thing about this graph is that it immediately gives insight in the assemblies and it’s dependencies. It is also possible to adjust the box size according to code complexity or lots of other factors. It is also possible to drill down into an assembly as you can see in the image below (Catel.Core drill down):


Analyzing the code quality

Every tool and set of rules has something to say about the quality of the Catel code. I always hope we don’t get smacked in the face too hard. All in all, I must say that the tool was merciful. This can either have to do with the small set of rules or the excellent code quality. Let’s keep it to the latter Winking smile


NDepend found 7 critical warnings. 4 of these are about a type being too big. We are indeed aware of this and are already working on a solution to this. The other 3 issues are about an internal type which has a lot of parameters (too much according to NDepend). But this doesn’t make it less true: it found the “least pretty” code easily. It’s definitely worth spending a day to improve and get rid of the warnings.

Customizing code analysis

Another very cool feature about NDepend is that they define the rules using LINQ statements. This means that if you do not agree with a specific rule on your code-base, you can simply customize it to your needs. For example, there is a rule that checks whether methods are potentially poorly documented. It does this by checking if at least 20% of the lines of code are used as comment in the method documentation. Sometimes you have a method which converts a string to a type. In such a method, there are a lot of type switches, so I want to customize this rule:

Now it only shows methods that are really poorly documented. This is an awesome feature which allows you to customize features by simply typing instead of having to compile rules into a separate assembly.


NDepend is a really helpful tool and I regret that I haven’t replaced FxCop with it earlier. It gives much better insight than FxCop and also integrates nicely with Visual Studio by analyzing the assemblies at runtime (just like ReSharper does). The advantage of this is immediate feedback which saves you time. Using tools like ReSharper and NDepend also makes learns you a lot about code quality and best practices.

My advice: give NDepend a spin and improve your code quality, in the end that’s what we all want!