valeriu.caraulean

Migrating to new csproj format

Sun, 18 Feb 2018 22:00:00 +0000

We’ve got a bunch of projects at work that are using the old style project file format. And since we’re already on Visual Studio 2017 and Rider, we were looking to new csproj format were the most interesting benefit would be it’s simplicity.

This is a how to guide on how to approach a such migration and description of few tricky moments and issues encountered.

Read the docs…

… or at least keep them at hand:

The new csproj format

Prerequisites

Using the Visual Studio Installer check that you have next components:

.NET Core cross-platform development workload
Targeting packs and SDKs for the version of the framework that you’re targeting

Upgrading the project

Simplest part. Replace the context of csproj with these lines:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
</Project>

Upgrading package references

Preparetive step, not strictly necessary. Go to Nuget settings of your IDE of choice and set “Default package management format” to “PackageReference”.

There’s an important difference while using new PackageReference compared to previous packages.config. New format includes only “top level” packages - ones that you reference directly in your code. As such don’t blindly add every package found in packages.config as a PackageReference. Instead:

Compile the project without any references
Follow compilation errors and edge them out one-by-one by adding missing packages

Cleanup & miscellaneous

Remove AssemblyInfo.cs. Check if it contains any useful attributes & set them in project properties or csproj directly
Remove packages.config
Remove packages folder in solution root

Dealing with embedded resources

If project contains any content/resource files, Include them explicitly in csproj:

  <ItemGroup>
    <Content Include="Mappings.csv">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

Or, as embedded resources using wildcards:

  <ItemGroup>
    <EmbeddedResource Include=".\**\*.json" Exclude=".\bin\**\*.json;.\obj\**\*.json" />
  </ItemGroup>

Nuget integration

The new msbuild took over for some manipulations related to nuget packages. So this area will need to be reviewed. Some particular items:

nuspec files, if used, have to be referenced from csproj files explicitly
nuspec files can be avoided completely and properties defined directly in csproj
nuget pack will not work anymore. dotnet pack or the equivalent msbuild /t:pack have to be used to generate nuget packages.

Actually, the common package related pattern will be: msbuild /t:restore;build;pack.

Pitfalls & possible issues

New project will pick up all .cs files in the project file directories and sub-directories. Some leftovers might get in the project. Fix: review & remove unnecessary.
Warnings about binding redirects. Fix: open app.config and remove mentioned assemblies.
Compilation errors in AssemblyInfo.cs about duplicated definitions. Fix: remove AssemblyInfo.cs
Output folder now includes target framework moniker. Example: bin\Debug\net462. If any build or deployment scripts are relying on old path, then it has to be fixed.
Additional files that have to exist in output folder aren’t automatically included. Fix: any additional resource files have to be included explicitly in new csproj.
Directory.GetCurrentDirectory() returns a different thing than before. Affects Directory.Exists, Directory.CreateDirectory and probably any other API that are accepting relative paths. Apparently, new CLI tooling is setting default Working Directory (in both VS2017 and Rider) to location of the project file, contrary to output folder.
nuget pack will not work anymore. dotnet pack or the equivalent msbuild /t:pack have to be used to generate nuget packages.

Build server woes (TeamCity)

We’ve got TeamCity on the build duty. Few things were needed there to support building of new project format:

Update Nuget Tools to a version that supports the new msbuild tooling (4.x will do)
To get the new msbuild tools on agents most reasonable option will be to use Build Tools for Visual Studio 2017.
If you’re getting this error: error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found. then install .NET Core Build Tools payload. Event if the app isn’t targeting .NET Core, this payload is still needed to correctly handle PackageReference in csproj.
Build configuration was probably stamping the assembly with version. Previously common approach was to update AssemblyInfo.cs before passing it to msbuild. As we got rid of this file, we can achieve same results by passing Version parameter to msbuild.

Timestamp accuracy and resolution in NLog

Tue, 12 Jul 2016 21:02:00 +0000

In one of internal projects we got a situation where our log management system was displaying entries from NLog in wrong “logical” order, despite being explicitly ordered by timestamp.

Here are few insights I got after investigating the case.

Let’s create a basic example to show the problem.

for (var i = 0; i < 100; i++ )
{
    _log.Info($"Iteration {i}: {DateTime.Now.ToString("HH:mm:ss.fffffff")}");
}

If we run this code with default NLog configuration, we will get output like this:

2016-07-11 16:14:23.8486343 Iteration 0: 16:14:23.8486343
2016-07-11 16:14:23.8486343 Iteration 1: 16:14:23.8496384
2016-07-11 16:14:23.8486343 Iteration 2: 16:14:23.8506392
2016-07-11 16:14:23.8486343 Iteration 3: 16:14:23.8526399
2016-07-11 16:14:23.8486343 Iteration 4: 16:14:23.8536741
2016-07-11 16:14:23.8486343 Iteration 5: 16:14:23.8546388
2016-07-11 16:14:23.8566766 Iteration 6: 16:14:23.8566766
2016-07-11 16:14:23.8566766 Iteration 7: 16:14:23.8576574
2016-07-11 16:14:23.8566766 Iteration 8: 16:14:23.8596377
2016-07-11 16:14:23.8566766 Iteration 9: 16:14:23.8596377
2016-07-11 16:14:23.8566766 Iteration 10: 16:14:23.8606376
2016-07-11 16:14:23.8566766 Iteration 11: 16:14:23.8606376
2016-07-11 16:14:23.8566766 Iteration 12: 16:14:23.8616403

As you see, multiple log entries are recorder with same timestamp (but check the timestamps in the message - they are much more varied). This looks fine if you’re looking in a console or in a single log file. But it will get quite annoying if you’re querying your log storage system and ordering results by time - sort order will be not what you would expect.

If we dig deeper in this problem, we will discover that NLog, has a mechanism called TimeSource. This provider is used to get the current time for each instance of LogEventInfo class created for every log entry in your application. There are a total of 4 different time source implementations, and, of course, you can create your own, if you please.

The default implementation of NLog’s time source is optimized for performance and caches the values that are being returned. Caching logic uses Environment.TickCount intervals to return time stamps for new log entries. And the resolution of TickCount property is limited to resolution of system timer which is not a fixed value but typically varies in the 10-16 ms range.

As a result, with default configuration, you get a timestamp resolution of ~15 milliseconds for your log entries.

Luckily, NLog provides other implementations of TimeSource. They are documented to an extend here. The default is the FastLocal and is has the caching behaviour I described above. FastUTC is using a similar caching approach but returning UTC timestamps. AccurateLocal and AccurateUTC, theoretically, should be better bets if you want a more precise timestamps in your log entries.

If we change our NLog configuration to use a more accurate time source:

<nlog>
  <time type="AccurateUTC" />
</nlog>

… then we will get a quite different picture in the output:

2016-07-11 21:20:32.5920090 Iteration 0: 23:20:32.5889709
2016-07-11 21:20:32.5939717 Iteration 1: 23:20:32.5929728
2016-07-11 21:20:32.5949707 Iteration 2: 23:20:32.5949707
2016-07-11 21:20:32.5959701 Iteration 3: 23:20:32.5959701
2016-07-11 21:20:32.6310051 Iteration 4: 23:20:32.6310051
2016-07-11 21:20:32.6330058 Iteration 5: 23:20:32.6330058
2016-07-11 21:20:32.6340033 Iteration 6: 23:20:32.6340033
2016-07-11 21:20:32.6370016 Iteration 7: 23:20:32.6370016
2016-07-11 21:20:32.6400059 Iteration 8: 23:20:32.6400059
2016-07-11 21:20:32.6766186 Iteration 9: 23:20:32.6766186
2016-07-11 21:20:32.6795909 Iteration 10: 23:20:32.6795909
2016-07-11 21:20:32.6826277 Iteration 11: 23:20:32.6826277
2016-07-11 21:20:32.6835886 Iteration 12: 23:20:32.6835886

Now we got a much better results: our logging timestamps are matching quite nicely timestamps from our message generated by DateTime.Now!

Both of the accurate time sources are using respectively current values of DateTime: DateTime.Now and DateTime.UtcNow. And this is giving us a better result, with timestamp resolution closer to 1 ms.

I actually wondered, how much is the difference in performance will be between fast and accurate TimeSource implementations? BenchmarkDotNet to the rescue! I quickly put together a benchmark that measured the difference between using different time sources. Results are quite interesting:

Method	Median	StdDev
FastLocal	5.7752 ns	0.3450 ns
FastUtc	5.8330 ns	0.4939 ns
AccurateLocal	784.4354 ns	61.6136 ns
AccurateUtc	7.0547 ns	0.3934 ns

Quite telling: fast implementations are the fastest but, as we’ve seen before, timestamps are cached and not that precise. AccurateUTC is a very close runner. If you’re asking, why is this not the default time source, the response probably will be the dreaded backward compatibility, as time sources were added around NLog 2.x.

Summing up

If you care about timestamps in your logs, change the default TimeSource to AccurateUTC. There’s a very small performance overhead, but you will get a much better accuracy and all your timestamps will be in UTC. Actually, the second gain (UTC timestamps), is extremely valuable when you have to deal with logging in complex or geographically distributed applications. So, please, consider it.

Handling custom URI Schemes with ClickOnce

Sun, 24 Apr 2016 15:00:00 +0000

This article will show how to handle URI schemes containing parameters in a ClickOnce applications. For example, a link like theapp://notificatons?eventId=124 can be handled by a ClickOnce application, where query parameters are passed in and can be handled by application itself. It’s also sometimes called deep link activation in a ClickOnce context.

URI scheme is a useful concept. It allows you to register an URI with your OS and then whenever an URL that corresponds to that URI schema will be clicked, you application will be launched. It’s very handy in some cases. Handling URI Schemes is well documented and, actually, quite simple. But it gets more though if you want to do it in a ClickOnce application in the case if you want to react to whatever is coming after URI scheme.

In our cases we wanted to send out emails with some specially formatted links (something like theapp://notificatons?eventId=124). When clicked, these links should open our application and then navigate to a “notifications” view and load details of a specific event. All this from a ClickOnce application. The hard part here is handling the URI arguments, thus the parts navigation and eventId=124 have to be available to the application.

We came with a way to do it and here’s a description how it can be done. And there are two ways to do it:

doing it properly: get rid of ClickOnce. If you can ditch ClickOnce - DO IT. Seriously.
the hard way: read on…

Implementation constraints, details & challenges:

ClickOnce application
Custom URI scheme
Application should be able to handle parameters encoded in URI like this: theapp://notificatons?eventId=124
Clicking on a such link should launch the application and allow the app to handle launch parameters
(constraint) The process should work even if Chrome is set as default browser
(limitation) Activation URI is a web address (approach is not handling apps installed from local or network paths)
(limitation) You have to launch application at least once manually to make it work

Show me the code!

You can jump straight into the code. I have a WPF project that I used to work on this feature and test activation. Code is on GitHub. Most interesting classes are ApplicationUriSchema.cs where all interesting things are happening and you might check also MainWindowViewModel.cs to see how to get the lauch URI and query string parameters. Application is logging all useful info and decisions, so watch the logs to understand what’s going on.

So, how this works?

The trick is to register as a command handler for our URI scheme the location of ClickOnce application. Then, when application is launched from via URI scheme, detect that and start new instance of ClickOnce application with parameters from the initial activation URL and shut down the current application instance. Parameters then are accessible in ClickOnce context via ActivationUri. We got 3 steps here.

1. Register application URI scheme

When application is launched for the first time it will update the Windows Registry to register URI with the application. The shell command that will handle the URI is set to the location of where ClickOnce executable is installed. That’s an unique location that changes every time a new version is installed. So every time a new application version is run for the first time, the registry settings that point URI protocol to command location are updated with new .exe file location

2. Restart application launched from URI handler with ClickOnce context

When application is launched from a link with corresponding URI schema two things are happening:

starting iexplore.exe with parameters list containing the URL to the application’s ActivationUrl and a query string containing parameters encoded in where a new process is started having as a launch parameters
shutting down current instance

3. Handling startup parameters from ClickOnce context

Now we’re running in ClickOnce context with ActivationUrl containing the ClickOnce location and a query string containing URL parameters from original link.

To sum up

Have a look at the code. But. It’s a hack and work-around. It’s not 100% bullet-proof and not pretty for users to see (ClickOnce launch dialog is shown then closed to leave place to new instance of application). But it worked for us, in our environment and user base.

But again, if possible, don’t tackle such things with ClickOnce. Step up and use a proper install/update/uninstall framework. WiX or Squirrel are just few alternatives…

Install and configure Elasticsearch in Windows

Mon, 07 Mar 2016 20:20:00 +0000

Recently I had to install & configure Elasticsearch and took some notes about it for further reference. Everything down here is actual at the moment of writing, March 2016 and Elasticsearch version 2.2.0.

Elasticsearch official site

Prerequisites

Java Runtime

Verify installed version of Java Runtime Environment or install it. Latest JDK 8 is strongly recommended.

Check available JDK using command line: java -version. Expected output: java version 1.8.0_73. Last numbers might be different, but 1.8 is expected.
Check system variables. Required environment variable: JAVA_HOME pointing to install location of JDK. Example:

JAVA_HOME: C:\Program Files\Java\jre1.8.0_73

Installation

Download zip file from https://www.elastic.co/downloads/elasticsearch.
Unzip downloaded file to location where your application will run from. C:\Program Files\Elasticsearch-2.2.0

Configuration

Location of configuration file: {install-path}\config\elasticsearch.yml. This is a text file using YAML format and that can be edited in any text editor.

Data folders

Uncomment lines containing path.data and path.logs keys. Set values to the location where elasticsearch should store indexes, documents and log files. Example:

path.data: D:\Elasticsearch\Data
path.logs: D:\Elasticsearch\Logs

Exposing elasticsearch endpoint over the local network

Uncomment network.host and set value to _site:

network.host: _site_

This will make elasticserch available under machine’s site name. Example: http://servername:9200.

Set the heap size

By default Elasticsearch will reserve 1 GB for it’s heap. For most installations it’s not enough. Set it appropriatelly to RAM available on your servers and server load. To set the heap size you have to create a system environment variable (more details here:

ES_HEAP_SIZE: 4g

Set field data cache size

If you have data that often changes or becomes obsolete (like log messages) it’s useful to set the field data cache size in your config file:

indices.fielddata.cache.size: 40%

(optional) Install web interface for monitoring

Recomended tool: kopf. To install, from {install-path} run next command:

{install-path}\bin\plugin.bat install menezes/elasticsearch-kopf/2.0

If install is failing to download or install check plugin’s homepage. If nothing works, download plugin to a temporary location and install it from a file:

bin\plugin install d:\temp\{path downloaded plugin zip file}

If even that is not working, unzip content of downloaded file to {install-path}\plugins\kopf and restart the service.

Plugin should be accessible at: http://servername:9200/_plugin/kopf

Configure to run as a service

Install elasticsearch service. Open command line and navigate to installation folder. Execute bin\service.bat install.
Open Services management console (services.msc) and find Elasticsearch 2.2.0 service. Change Startup Type to Automatic. If you need to run the service under a specific user account that’s the place to set that up.
Start the service

Checks (post-configure & post-install)

After starting the service check logs for any errors.
Open http://machinename:9200/ in browser. No web page is opened but request should succeed by returning a JSON response or a file (depending on the browser).
If any of monitoring plugins is installed check there the state of your cluster and nodes (for example on http://machinename:9200/_plugin/kopf)

Setting up a basic cluster

If you want the simplest configuration but you want a your cluster to have some redundancy and good performance - then Elastic’s default settings will work well for you. Say, for redundancy and query distribution you want to run an ES cluster on 2 (or n nodes). Then your starting point will be a very basic elasticsearch.yml (example for 2 nodes):

First node:

cluster.name: my-es-cluster
node.name: my-es-node-one
network.host: _site_            # this will make ES available via host/mashine name
http.port: 9200                 # listening endpoint
discovery.zen.ping.unicast.hosts: ["es-host-1", "es-host-2"]

Second node:

cluster.name: my-es-cluster
node.name: my-es-node-two
network.host: _site_
http.port: 9200
discovery.zen.ping.unicast.hosts: ["es-host-1", "es-host-2"]

Notice that the only difference is the node name.

Pretty self-explanatory. This should be enough to get you a working cluster of 2 boxes where both nodes will be master-eligible and data nodes and only one node will be playing the role of master node. But you can still query getting them processed on any of nodes. More about network settings

Using Caliburn.Micro with async/await

Mon, 15 Jul 2013 11:21:00 +0000

This post will give an overview of how you can use async/await features from C# 5.0 with Caliburn.Micro (CM). If you’ve found an error or want to complete the content please let me know in the comments. A sample application demonstrating async/await interactions in CM is available on GitHub.

Setting it up

To use Tasks and async/await features you need the latest version of Caliburn.Micro. Support for Tasks was introduced in version 1.5, so you’ll need a version higher than that. And, of course, you need .NET Framework 4.5 or higher. All examples in this post were tested in a WPF application targeting .NET 4.5 framework. However, same code will be probably valid for Silverlight, WP8 and Windows8 apps.

Create and configure new project to test the concepts

Create new WPF 4.5 application
Install Caliburn.Micro from nuget. You’d better choose the Caliburn.Micro.Start package as it has everything required to run a Caliburn application (boostrapper, container, main screen)
Change App.cs to correctly bootstrap with Caliburn, here is how to do it

Async Actions

The syntax for attaching actions in XAML will remain unchanged:

<Button x:Name="RunTask1Async">
<Button cal:Message.Attach="RunTask1Async">

When declaring action’s method we can specify that we want to handle it asynchronously:

    public async void RunTask1Async()
    {
        Log("RunTask1Async - starting a 4 second task");
        await Task.Delay(4000);
        Log("RunTask1Async completed");
    }

And that’s all you need to execute an action asynchronously (if you have to execute a Task).

Async handlers for Screen events and overrides

CM offers few handy methods that allow to connect to Screen’s lifetime events. Some method overrides with async signatures:

	protected override async void OnInitialize()
	{
		Log("OnInitialize - starting a 7 seconds task");
		await Task.Delay(7000);
		Log("OnInitialize completed");
	}
    protected override async void OnActivate() { }
    protected override async void OnViewLoaded(object view) { }
    protected override async void OnViewAttached(object view, object context) { }
	...

To note here that even if the method in base class is not marked async, our overrides declare them with async modifiers and it runs fine.

Similarly, you can handle Screen’s events the same way how you’re handling any .NET event in asynchronous way:

	{
		// ...
		ViewAttached += OnViewAttachedEventHandler;
	}
	private async void OnViewAttachedEventHandler(object sender, ViewAttachedEventArgs args)
	{
		Log("OnViewAttachedEventHandler- starting a 1 second task");
		await Task.Delay(1000);
		Log("OnViewAttachedEventHandler completed");
	}

IHandleWithTask interface

This is a new addition to CM, declared as:

    public interface IHandleWithTask<TMessage> : IHandle
    {
        Task Handle(TMessage message);
    }

It’s extremely useful when you want to handle a particular message using a Task and off-load application’s main thread.

An example:

	public class Message { }

	public class MessageHandler : IHandleWithTask<Message>
	{
		public MessageHandler(IEventAggregator eventAggregator)
		{
			eventAggregator.Subscribe(this);
		}

		public async Task Handle(Message message)
		{
			await Task.Delay(3000);
		}
	}

Convert coroutines to Tasks

This can be done easily by using an extension method:

	public async void WrapIResultInTaskAsync()
	{
		await new SimpleCoroutine().ExecuteAsync();
	}

“async void” or “async Task”

A great question will be: should I use async void or async Task as a return value of action methods, screen’s events and overrides? Since you can do both and the code will compile and run mostly fine, let’s see what Stephen Cleary writes about it in Best Practices in Asynchronous Programming article:

You should prefer async Task to async void. Async Task methods enable easier error-handling, composability and testability. The exception to this guideline is asynchronous event handlers, which must return void. This exception includes methods that are logically event handlers even if they’re not literally event handlers (for example, ICommand.Execute implementations).

I will join this recommendation. Actions are event handlers at their core, normally they are executed as “start and forget”. If something happens (an exception), it will be handled at application level. For the case when you want to handle any exceptions locally, you may want to create an override which returns an async Task. Also, this will allow calling same method action from another part of the program or write a unit test to verify an asynchronous process.

References

This is pretty much it. If you’ve found an error or may complete this post with additional info, let me know in the comments.

Book review - NoSQL Distilled

Fri, 14 Dec 2012 09:38:00 +0000

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence by Martin Fowler and Pramod J. Sadalage.

For some time already I’ve been keeping an eye on rising popularity of NoSQL. From reading articles and blog posts about various aspects and flavors, I adventured myself and dived more deeply into RavenDb, a NoSQL Document Database. Still, the picture I had in my mind was somewhat blurry and had few areas where I wasn’t sure that I understand some basic things. This book is a very good starting point into NoSQL world. It starts with explaining the rise of popularity of NoSQL solutions for multiple domains and modern data storage requirements. Then it explains important concepts around NoSQL data stores like aggregation and distribution models, consistency, versioning and Map-Reduce. The second part of the book takes a look at each family of NoSQL flavors and analyzes their features, data modeling challenges and applicability of concrete database in various domains. Key-Value databases are presented by Riak, Document Databases by MongoDB with few mentions of RavenDb, Cassandra represents the Column-Family store type, and, final group, the Graph databases are explained using Neo4J. Last chapters of the book talk about schema migrations, data storage options outside of NoSQL area and what you should consider when choosing a database.

One of the ideas frequently discussed trough the whole book is why people are choosing NoSQL solutions:

There are two primary reasons for considering NoSQL. One is to handle data access with sizes and performance that demand a cluster; the other is to improve the productivity of application development by using a more convenient data interaction style.

Most often when you speak about NoSQL with somebody the reaction looks like “ah, that thing that Google and Amazon runs on thousands of servers”. And nobody who only have heard of NoSQL is sensing the second great advantage of these systems: improving productivity and flexibility of your development team and make the life of application developer easier.

NoSQL doesn’t means a complete schema-less data storage. Instead of having rigid definitions of schema and relationships as in the world of Relational Database, the shape of data is defined by application itself. That is, application is defining how it wants to store and access the data. No more you have to fight the impedance mismatch between relational model and in-memory data structures. Forget the performance penalization of an ORM, limitations of relational model in querying, aggregating and shaping data. Instead, your application defines the aggregate model and naturally persist it. Then it has reach options to slice and dice stored data, perform flexible Map-Reduce transformations and offers reach analytical capabilities. This allows development teams to be more flexible and productive when building complex systems. When your data storage is a simple commodity, easy to access and manipulate, you will have much more time to work on your domain, business logic or User Interface.

Each kind of NoSQL implementation offers it’s own advantages and has it’s weak points. For me the most interesting are the Document Databases like MongoDB and RavenDb. They will suit a very broad range of applications because of the notion of a Document - something with properties and values aggregated in one entity stored as a simple JSON document. This will give you ability to index documents, write rich document based queries and much more.

Summary

A great overview of existent NoSQL technologies, their characteristics and applicability of each of them in various domains. The book is short as it was really meant as an overview, not a deep dive in these technologies.

At the moment when I write this review Amazon places this book as #1 in Databases category and #2 in Databases/SQL, it has 15 reviews with an overall score of 4.5.

Highly recommended.

Do less and achieve more with RavenDb

Thu, 15 Nov 2012 09:40:00 +0000

If you’re after a document database for a .NET application it’s hard to miss the buzz around RavenDb. Although there are many other NoSQL databases that are getting much more attention and popularity, RavenDb distinguishes itself by being a native in .NET ecosystem while still offering great value as a generic, technology agnostic data store.

Dealing with Relational Databases, SQL and Object-Relational Mapping are probably the most omnipresent skills in any developer’s career. But take a .NET dev with a good background in modern database technologies and let him play few hours with RavenDb and I guarantee that he’ll come back impressed.

And there is a good reason for that. One of the most impressive things is how easy it to define a class, fill it with data then just throw it in the store. Then load it back an put it on the screen or send over the wires. All this without any object-to-database mappings, no transformations, no base classes; with only few lines of configuration and initialization code. It’s fascinating when you’re an ORM veteran and experience it for the first time…

I won’t go over all of the features of RavenDb. I will just touch few points that, in my opinion, can drastically reduce the amount of infrastructure code of almost any application, be it a client-server “enterprise-grade” system, web site / service or even a rich desktop application.

Disclaimer: YMMV. I’m writing about things I’ve seen or experienced myself.

Reduce your mapping layers

Things you probably (or certainly) will not need with RavenDb:

Maintain a mapping layer to fit your domain model in a relational database with it’s rules and constraints
Keep on the eternal fight with lazy relations
Map your domain to DTOs and backwards when you’re talking over the wires (especially using WCF)
Map the DTOs to client side models and view models

All this stuff is code. Code to be written, tested and maintained. Take this code and throw it away. Feel better now? I’m glad for you…

Of course you’ll have some mapping code. As example you’ll probably have to shape your documents to display them on the screen or create static indexes. But I’d consider it as a business/domain concern and not just plumbing code to please your communication layer or mapping framework.

Cut through your infrastructure

What I love in RavenDb is that it’s not a mere data store. It comes with a bunch of features and bundles that aren’t directly related to persist and query data, but are much more like functional or business components for your application covering real feature requirements. Examples?

Search

Any reasonably sized and feature rich application that is manipulating data records is incomplete without an embedded search feature. In .NET world the choice is extremely limited. You’ll probably choose the Lucene.NET, write code to sync your search indexes with database/domain changes, then, run scary with the hope to never have to touch that code again. If you’ve worked with Lucene.NET, you know what I’m talking about…

Much of the RavenDb powers are based on Lucene.NET. But you’ll barely observe it hidden behind a friendly API and the “usual suspect”, LINQ.

Security

You never meet a stakeholder or client obsessed about security? Move on to the next point…

Authorization is hard: Users, Roles, Operations, Permissions. Then add row level security. Oh my, it’s really hard. And it’s even harder to get it working properly and with minimal penalization on performance. I think because it’s a tough challenge there aren’t many generic solutions for this problem.

RavenDb comes with Authorization Bundle. The only thing you have to do is to define your rules and (when required) add additional checks for constraints in your business or domain logic.

Client notifications

It’s called Changes API, it let’s your client know when a document changes on the server. I’ve been there, done that:

Whenever NHibernate detects a change, send a message about it to a queue.
Have a service listening to that queue.
When there’s a message, notify all interested subscribers about it.
Over WCF. Duplex channel. Silverlight…

And I still have known bugs in that subsystem.

Now take all this stuff and throw it away. Using RavenDb’s client API you can subscribe to change events of a single document, a document type or index. An the awesome part - it implements IObservable from Reactive Extensions. Ditto.

Versioning/Audit

With Versioning Bundle RavenDb will keep the history of changes made to a document. With the audit trail you’ll be able to find who changed what and when. Depending on your architecture it may be very simple to implement basic audit infrastructure. But it’s a much more challenging task to keep around modifications and with relational model is very hard to revert changes when your records were stored in database. With Versioning Bundle it’s easy to plug in and know everything.

To refrain: all this stuff is code. Code to be written, tested, maintained.

And one more thing. All this components are written by the authors of RavenDb. While I’m confident in my skills, I know my limits. I wouldn’t be able to do a better job integrating with a third-party system than the people who wrote it from scratch.

I’ve highlighted only some of typical parts of a reasonably complex software system but there are more, of course. With RavenDb you already have functional blocks ready for integration and use. This is a point to consider when time-to-marked is critical or you care about your product. And less of a concern when you’re only after your monthly paycheck.

Even if you have already some of these subsystems in place and are using “typical” architecture with a service layer, ORM and relational database, you should seriously consider RavenDb while you’re at early stages of your product.

Because with RavenDb you can do less but achieve more by focusing on things that really matter: your domain model, business knowledge and that bizarre wrapper around it, called User Interface.

Diving deeper in Reactive Extensions, concurrency

Tue, 09 Oct 2012 22:04:00 +0000

I’ve started using Reactive Extensions, Rx library without digging too much in it’s internals. Had a case where I wanted to filter a stream of events and decided I’d try something new for me, Rx. But as it always happens with powerful and flexible tools, starting with few superficial articles and examples from the Web without diving deeper in the concepts is a pretty bad idea.

This time I’ve been bitten by concurrency issues. And the best resource I’ve found so far is the Introduction to Rx ebook by Lee Campbell. It costs only around a buck on Amazon and it’s available for free from the site.

I’ve jumped straight to the Chapter 4, Concurrency and for surely will pass without a hurry over the rest of the book. This chapter has an nice check list about best threading options for some scenarios:

UI Applications

The final subscriber is normally the presentation layer and should control the scheduling.
Observe on the DispatcherScheduler to allow updating of ViewModels
Subscribe on a background thread to prevent the UI from becoming unresponsive
- If the subscription will not block for more than 50ms then
  - Use the TaskPoolScheduler if available, or
  - Use the ThreadPoolScheduler
- If any part of the subscription could block for longer than 50ms, then you should use the NewThreadScheduler.

Service layer

If your service is reading data from a queue of some sort, consider using a dedicated EventLoopScheduler. This way, you can preserve order of events
If processing an item is expensive (>50ms or requires I/O), then consider using a NewThreadScheduler
If you just need the scheduler for a timer, e.g. for Observable.Interval or Observable.Timer, then favor the TaskPool. Use the ThreadPool if the TaskPool is not available for your platform.

And by the way, on author’s blog I’ve found another interesting series of articles: Responsive UIs in WPF - Dispatchers to Concurrency to testability. That’s something I’d be reading after sorting out concurrency issues from my code.

Visual Studio 2012 dark theme tip - light up your UserControl in XAML designer

Thu, 30 Aug 2012 23:35:00 +0000

I really like the new Visual Studio 2012. And the dark theme looks cool and is so much easier for the eyes.

But there is a real problem when you’re working with User Controls in designer. And we have lots of them. What is the problem then? Look at the picture:

Yup, that is a UserControl with few elements on it. With a default transparent background it’s is hardly visible on design surface. In runtime, when put on a parent (usually a Window) it will take background of the parent and all elements will be visible.

Looking trough the VS2012 settings I’ve seen options to customize Windows Form Designer, Workflow and HTML Designers but nothing about customizing the XAML designer. Pretty bad, Microsoft.

In this case Styling comes to the rescue! With some styling and by using a trigger to enable the style only for Design Time, we’ll get this:

Much better now! To achieve it you have to put a small XAML fragment in your Generic.xaml or App.xaml and you should be done:

<Style TargetType="{x:Type UserControl}">
    <Style.Triggers>
        <Trigger Property="ComponentModel:DesignerProperties.IsInDesignMode"
                 Value="true">
            <Setter Property="Background"
                    Value="White" />
        </Trigger>
    </Style.Triggers>
</Style>

That’s how you’ll have your views well visible (and actually, design-able) in dark theme.

Update:

I’ve looked again if there are any options in Visual Studio 2012 to lighten a bit the dark background in designer. And found an issue reported on Microsoft Connect about this very problem. Unfortunately, this is “by design” and cannot be customized, at least yet:

Yes, this is an unfortunately limitation in Visual Studio 2012 RTM. We would have loved to have the ability to change the default background color of the design surface, but could not get around to it (we have it on our backlog).

And a user has even posted a workaround that is mostly the same as above…

Evening time, time for fun

Tue, 28 Aug 2012 21:07:18 +0000

Or for whatever keeps you entertained…

This evening it started when I looked how to make Windows Live Writer store drafts in my SkyDrive. As usual, started with googling it. Found a trick with a registry key that should point WLW to any folder I want. Nice trick, except it was not working on my PC.

Why a trick that works for other people isn’t working in my machine?! This hooked me up and it ended badly. In about 2 hours I’ve:

Poked around WLW’s registry settings
Run procmon & procexp on WindowsLiveWriter.exe
Decompiled Windows Live Writer using dotPeek
Got a rough picture of WLW’s code structure and some knowledge of it’s initialization procedure
Found the code that handles custom folder and seen that it should work as the trick described
Learned from code that WLW can run in portable code and how to do it
Learned how to use Just-In-Time Debugger to launch an .exe file and attach the Visual Studio’s debugger from application’s start
Failed to make WLW crash so I can break in debugger
Learned about setting a function breakpoint, and that’s useless without symbols
Gave up…

Then I had a glass of Talisker and before giving up completely tried again the trick with registry key…

It. Worked.

Moral of the story – stupid, evident errors happen all the time. And, sadly, it takes time to recover. You’re lucky if you’re not under pressure, running to deadline or doing a demo. And you’re really lucky if you can learn new things on the way and keep yourself entertained :)