Rash thoughts about .NET, C#, F# and Dynamics NAV.

"Every solution will only lead to new problems."

Monday, 8. April 2013

Stati-C/AL Prism – Static analysis for Microsoft Dynamics NAV reloaded

Filed under: Dynamics NAV 2013,F#,Navision — Steffen Forkmann at 9:07 Uhr

Christian Clausen and Bent Rasmussen released their second static analysis tool for Dynamics NAV called Prism. This time it has more features and it’s even faster than Supervision.

“Load time for Developers Toolkit for a typical full database is approximately 25 minutes which compares to Prism’s 20 seconds. Load time is a serious productivity and/or quality killer, as people will either work with old objects in Developers Toolkit, wait another 25 minutes to reprocess the objects, or even decide to just go ahead and change code without understanding how the current code is actually working.”

[project page]

The biggest new feature is “Find usages”:


Check out the project page and watch the presentation at the Community for F# which gives some details about the implementation.

Tags: ,

Friday, 5. April 2013

Stati-C/AL Supervision – blazing-fast static analysis for Microsoft Dynamics NAV

Filed under: Dynamics NAV 2009,Dynamics NAV 2013,F#,Navision — Steffen Forkmann at 17:26 Uhr

Until yesterday I thought I would be the only person on this planet who plays with a combination of F# and Dynamics NAV. Turned out I was wrong. Smiley

Christian Clausen and Bent Rasmussen created a really really cool static analysis tool for Dynamics NAV written in F#. For those who worked with the Dynamics NAV Developer’s Toolkit this is your new friend:


“Supervision is a free software program which can transform C/AL object text files into color-coded hyper-linked interactive HTML files.

The purpose of Supervision is to give Microsoft Dynamics NAV developers an easy and intuitive way to browse C/AL source code which provides better insight into the semantics of C/AL programs.”

[Project page]

Some of the features are:

  • Produces HTML/JavaScript code from Microsoft Dynamics NAV text export files
  • Usages of user-defined functions, variables, parameters, fields, system-defined variables, and object types link to their declaration
  • Usages of C/AL system functions link to official Microsoft C/AL language documentation
  • Code coloring
  • It’s blazing-fast Zwinkerndes Smiley

Check out the project page and watch the presentation at the Community for F# which gives some details about the implementation.

Tags: , ,

Wednesday, 3. April 2013

A tale of nulls – part I

Filed under: F#,Informatik — Steffen Forkmann at 17:43 Uhr

Triggered by a short tweet by Tomas Petricek and a blog post by Don Syme I had a couple of conservations about null as a value, Null as a type (Nothing in Scala), the null object pattern and the Maybe monad (or Option type in F#). I decided to share my opinion on this topic in order to help others to make their own opinion.

Part I – Null as a value

Unfortunately most programming languages have some kind of null pointer. We are now even at a point where some people claim that Tony Hoare’s famous billion dollar mistake costs actually a billion dollar per year.

But before we start to think about solutions to the null pointer problem let us first see where null values might come in handy.

Uninitialized values

In a statement oriented language like C# it is sometimes not that easy to represent uninitialized state.

As you can see we forgot to initialize peter in the missing "else-branch" which might lead to a NullReferenceException. There are a couple of things we can do to prevent this from happening. First of all we should omit the explicit initialization with null:

In this case the C# compiler throws an error telling us "Use of unassigned local variable ‘peter’".

In expression oriented languages like F# the problem doesn’t exist. We usually write initializations like this:


There is no way to forget the else branch since the types don’t match.

Unknown values

Consider a search function which tries to find a Person in a list:

Unknown values are probably the most common cause for the introduction of nulls and in contrast to uninitialized values they have much more global effects.

Solutions to unknown values

1. Using explicit exceptions

One easy solution to get rid of the nulls is to make the exception explicit:

One benefit here is that we have a concrete exception which is telling us what went wrong. Unfortunately nothing forces us to handle this exception in the calling method. This means the program can still crash. Another problem is that if we use try/catch as a control flow statement (i.e. use it very very often) then we might slow down our program.

And there is still a philosophical question: is it really an exception if we don’t have a person in our repository?

2. Using out parameters and returning bools

If we want to make the result of our search a little more explicit we can also introduce a boolean return value:

This is a pattern which is actually used everywhere in the .NET framework, so it must be good right?!

Just a simple question here: What did we gain exactly? If we forget to check for nulls why would we remember to check the bool?

There is another interesting observation here. Due to the introduction of out parameters we also introduce the uninitialized value problem in every calling method, which is bizarre.

3. Null object pattern

“In object-oriented computer programming, a Null Object is an object with defined neutral ("null") behavior. The Null Object design pattern describes the uses of such objects and their behavior (or lack thereof).”


So obviously this makes only sense in a context where objects have observable behavior. So let’s add some behavior to our Person class:

Let’s look at this solution for a moment.

  • Pro: Implementation of missing behavior is trivial
  • Pro: We don’t introduce null values –> we won’t get NullReferenceExceptions
  • Pro: The name of the class carries information about the reason for the null value
  • Cons: In order to to get rid of the Person(string name, int age) constructor in the null-object we had to introduce an interface
  • Cons: In order to use the interface we had to modify the Person class. This might be a real problem if we don’t have access to the source. We would need some kind of ad-hoc polymorphism like Haskell’s type classes, Scala’s Traits or Clojure’s Protocols (read more about the expression problem)
  • Cons: Everything we want to do with Persons has to be part of the IPerson interface or we have to fall back to explicit runtime type tests, because there is no way to get to the data:


  • Cons: Without ad-hoc polymorphism the Person class is getting more and more complex over time since we are adding all the behavior to it. Compare it with our starting point where it was a simple data representation. We totally lost that.
  • Cons: Errors/bugs might appear as normal program execution. [see Fowler, Martin (1999). Refactoring pp. 261]

Don’t use this approach it’s really not a good solution.

4. The Option type (a.k.a. Maybe monad)

The option type is a way to push the idea from 2. “returning bools” into the type system. There are lots of tutorials about the option type on the web, but for now it’s enough to know that it is something which is based on the following idea:

In order to allow pattern matching in C# we introduce a small helper:

With this idea we can get rid of all null values in the program, we don’t have to introduce an IPerson interface, the null case is type checked and the best thing is it’s really easy to create functions like IsOlderThan12:

Please don’t implement the option type yourself. Even in C# it’s much easier to just reference FSharp.Core.dll and use FSharpx (read 10 reasons to use the F# runtime in your C# app).

Of course this is only the tip of the iceberg. If you read more about the option type you will see that its monadic behavior allows all kinds of awesome applications (e.g. LINQ, folds, map, …).

5. The Either type

One of the benefits of the null object pattern above was that it allows to encode the reason for the missing value. In some cases we need the same thing for the maybe monad. So let’s try to capture the reason in the None case:

Now we can use this in the TryFindPerson method:

As with the option type please don’t rewrite this stuff yourself. There is a Choice type in F# which helps to capture this idea and Mauricio has a couple of blog posts which explain how to use it from C# (of course FSharpx is helping here again).

6. The (singleton) list monad

The option type captures the idea that we can either have one value or nothing. We can do the same thing with List<T>:

Of course this uses only a small subset of the power of IEnumerable<T> but I wanted to show the similarity to the maybe monad. You can read more about the “poor man’s option type” on Mauricio’s blog.


We saw a couple of very different solutions to get rid of null values. Normally I’d only use the option type or the either type (if I need to carry the reason). In some very rare situations (e.g. C# only projects) I would also use singleton lists.

I wouldn’t use the other solutions. They are potentially dangerous, especially if your project gets bigger.

I would be happy to read your opinions.

Tags: , ,

Wednesday, 27. March 2013

FSharpx 1.8 removes support for Freebase, CSV, JSON and XML document type providers

Filed under: F# — Steffen Forkmann at 18:25 Uhr

There was a lot of confusion about the document type providers in the last couple of months. The reason was Tomas Petricek and Co. worked on an improved version in the FSharp.Data project and most people lost track which feature was in which project.

In order to make things clearer I removed the Freebase, CSV, JSON and XML type providers from the fsharpx project. From now on they are only in the FSharp.Data project (on github and nuget).

I hope this doesn’t make things worse and I apologize for the confusion. On the bright side you now get a couple of new features and a really cool documentation.

You can read more about this on Tomas’s blog.

Tags: ,

Thursday, 7. March 2013

New tasks for building Xamarin Components in FAKE – F# Make

Filed under: F#,FAKE - F# Make — Steffen Forkmann at 12:50 Uhr

The current version of FAKE contains two tasks for Xamarins xpkg format. These are already used in Daniel Nauck’s Portable.Licensing project (read more about this project).

Sample usage:

Thank you Daniel for this contribution.

Tags: ,

Wednesday, 6. March 2013

License all the things with Portable.Licensing 1.0

Filed under: C#,F# — Steffen Forkmann at 10:20 Uhr

"Portable.Licensing is a cross platform open source software licensing framework which allows you to implement licensing into your application or library.

It is targeting the Portable Class Library and thus runs on nearly every .NET/Mono profile including Silverlight, Windows Phone, Windows Store App, Xamarin.iOS, Xamarin.Android, Xamarin.Mac and XBox 360. Use it for your Desktop- (WinForms, WPF, etc.), Console-, Service-, Web- (ASP.NET, MVC, etc.), Mobile (Xamarin.iOS, Xamarin.Android) or even LightSwitch applications."

[Project site]

Yep, you read this correct. This project gives you a free licensing tool for all .NET/mono platforms including stuff like Android and iOS. It’s hosted on github and already on nuget and the Xamarin store, so it’s pretty easy to use – even from F#.

Create a license

There is a really good documentation on the github project page (and there is even a sample implementation for a License Manager app), but just to give you a small glimpse:

Make sure to keep the private key private and distribute the public key with your app.

Validate a license

So try it out and don’t forget to thank Daniel Nauck for this awesome new tool.

Tags: , , ,

Sunday, 27. January 2013

Released new AssemblyVersion tasks for FAKE

Filed under: C#,F#,FAKE - F# Make — Steffen Forkmann at 16:11 Uhr

Today I released two new AssemblyInfo tasks for FAKE and marked the old one as obsolete. One advantage of the new tasks is that they only generate the specified attributes and no more. There are already a lot of predefined attributes but it’s also possible to specify new ones. Here is a small example:

Tags: , ,

Tuesday, 11. December 2012

Testing, proving, checking – How to verify code properties

Filed under: F#,Informatik — Steffen Forkmann at 13:12 Uhr

As programmers we often want to express that a special property holds for a method, e.g. we want to say that the associativity law holds for list concatenation. In F# we could define a concat method like this:

As programmers we could write a couple of unit tests which try to check the associativity law. With NUnit enabled we could write this:

But the question is: did we cover all interesting cases? In computer science we have a method to prove that the property holds for all lists. This methods is called structural induction (see also this video lecture by Martin Odersky) and would look like this:

1) Rewrite the code as equations
concat ([],ys)    = ys                  [CON1]
concat (x::xs,ys) = x :: concat(xs,ys)  [CON2]
2) Rewrite the property as an equation
concat(concat(xs,ys),zs) = concat(xs,concat(ys,zs))
3) Check the base case
= concat ([],zs) // using CON1 = [] // using CON1

= concat (ys,zs) // using CON1
= [] // using CON1
3) Show the inductive step

= concat (x::concat(xs,ys),zs)) // using CON2
= x :: concat(concat(xs,ys),zs) // using CON2
= x :: concat(xs,concat(ys,zs)) // induction hypothesis
= concat(x::xs,concat(ys,zs)) // using CON2

This math is very clean and shows that the associativity law holds for all lists. Unfortunately even with a slightly more complicated sample this gets at least tricky. Try to prove that reverse(reverse(xs)) = xs with reversed defined as:

As you will see the naïve approach with structural induction will fail (for a nice solution see this video lecture).

There is even a bigger problem with the proof: one assumption of induction is referential transparency of the given functions. We can’t always assume this.

So we can’t always (easily) proof code properties and we don’t want to write too many unit tests – then what can we do?

One compromise solution is to use a tool which systematically generates instances for our tests. There are a couple of tools out there, e.g. there is QuickCheck for Haskell or PEX for .NET. In F# we can use a tool called FsCheck:

Of course a test like this doesn’t prove that the property holds for all lists, but at least it verifies all bases cases and probably a lot more cases than one would manually do.

If you introduce a bug you get a nice report, which even shows a counterexample:


It’s even possible to add these tests to your test suite and to run them during the CI build. So don’t stop at classical unit test – check code properties!


Using Footloose from F# – part I – Setting up the infrastructure

Filed under: F# — Steffen Forkmann at 9:09 Uhr

“Footloose is a fast and scalable asynchronous distributed computing and service library that was designed to be secure, simple to use, unobtrusive and without the need of client side code generation or proxy classes.

It was developed to connect or build distributed applications on the .NET/Mono platform with enterprise features like load-balancing, clustering, encryption, service discovery and single-sign on.

Footloose enables you to easily transmit any kind of data between the components of your application over thread-, process- or physical boundaries. Depending on your needs Footloose uses one if its transport channels, e.g. a Named Pipe or a Unix Socket for Inter Process Communication (IPC), AMQP with one of the available Message Broker implementations (like RabbitMQ) in the local network or even XMPP as a secure and fast realtime messaging protocol that enables you to build cloud services.”


If you don’t like WCF then you should really check out Footloose.
Footloose_IconToday I want to show you how to use Footloose in a very simple sample with F#.

As a first step we create a F# project for the service contracts. Inside this project we need a service definition like this:

This is just a definition of the remote service and the data. Now we create a F# console project for such a service and reference the service contracts project. We start by implementing the service like this:

Now we use nuget to retrieve the latest version of Footloose. At the time of writing we need to install the pre-release of version 3.0 by "install-package Footloose -pre". In the Program.fs we add the service configuration. Here Footloose wants us to specify the endpoint name, transport channel and a serializer. In order to get Footloose working we also have to retrieve a trial license from the website.

Footloose wants us to provide a ServiceLocator in order to resolve the service. Normally you would use a DI container for this, but here it’s sufficient to fake a IServiceLocator like this:

In the next step we create another F# console project for the client, reference the service contracts and install Footloose ("install-package Footloose -pre"). We also need to install FSharpx ("install-package FSharpx.Core") in order to use the "Quotation to Linq Expression" stuff and the new task monad. Now we are ready to build the client:

As you can see we set up the connection and wrap our service call inside a task monad. The most interesting part is calling the service. Footloose wants to us to provide a LINQ expression:

In order to make the client code compile we also need an active pattern which transforms the service result into something we can pattern match:

As the last step we configure the solution to start both projects and run the sample:


The result should look like this:


The sample code is now part of the FootlooseExamples project on github.

Tags: ,

Tuesday, 18. September 2012

Dev Open Space 2012 – 19.-21.10.2012 in Leipzig

Filed under: Coding Dojo,F#,NaturalSpec,Veranstaltungen — Steffen Forkmann at 7:08 Uhr

Open Source. Open Space. Developer Open Space Nachdem es sich die letzten beiden Jahre mehr und mehr angekündigt hat, wurde der .NET Open Space in Leipzig nun in Dev Open Space 2012 umgetauft. Dies trägt dem Punkt Rechnung, dass die Themenwünsche der Teilnehmer immer breiter geworden sind und wir uns vor allem auch über git, Ruby, JavaScript, HTML5, node.js, CQRS und vieles mehr unterhalten haben. Weiterhin wird es natürlich trotzdem noch reine .NET-Themen geben.

Neu sind außerdem die kostenlosen Workshops die bereits einen Tag vor dem OpenSpace angeboten werden. Ich selbst werde einen zu F# und Test Driven Development halten:

“Test Driven Development (TDD) bringt viele Vorteile für den Code aber erfordert auch eine Menge Übung. Dieser Workshop zeigt, wie man TDD mit F# mittels NaturalSpec and NCrunch erfolgreich einsetzt. NaturalSpec ist ein F#-TDD- Framework, mit dem Unit Tests auf sehr intuitive Weise ausgedrückt werden können. NCrunch hilft, diese Tests ständig (bei jedem Tastendruck) auszuführen. Das zusammen ergibt einen sehr schnellen Feedbackzyklus und TDD wird deutlich schneller. Nach einer kurzen Einführung in die Tools werden im Workshop gemeinsam kleine Programmieraufgaben gelöst.”

Die Anmeldung ist bereits möglich.

Tags: ,