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

"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.

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:

Today I’m happy to annouce that we have a new type provider in FSharpx. Yesterday I ported the WMI type provider from the F# sample pack and released it as a nuget package. This type provider allows to use Intellisense on data from the Windows Management Instrumentation (WMI).

Create a new F# project in Visual Studio 2012 and install the FSharpx.TypeProviders.Management package via nuget. The package manager references two libraries and you have to remove the reference to Samples.Management.TypeProvider.DesignTime manually. After you reference System.Management you can start to access WMI:

You can find a lot more samples in the F# Sample pack.

The “Walkthrough: Creating and Interacting with a Page Web Service (OData)” shows how we can easily access Dynamics NAV OData from the default company:

But somewhere in this process there seems to be a bug. If I want to access data from a different company I get a timeout:

I found a workaround for this, but if anybody knows more about this please write a comment.

In my last post I described how we can access Dynamics NAV 2009 SOAP web services from F# and the benefits we get by using a type provder. Since version 2013 it’s also possible to expose NAV pages via OData. In this article I will show you how the OData type provider which is part of F# 3 can help you to easily access this data.

Exposing the data

First of all follow this walkthrough and expose the Customer Page from Microsoft Dynamics NAV 2013 as an OData feed.

Show the available companies

Let’s try to connect to the OData feed and list all available companies. Therefore we create a new F# console project (.NET 4.0) in Visual Studio 2012 and add references to FSharp.Data.TypeProviders and System.Data.Services.Client. With the following snippet we can access and print the company names:

As you can see we don’t need to use the “Add Service Reference” dialog. All service type are generated on the fly.

Access data within a company

Unfortunately Dynamics NAV 2013 seems to have a bug in the generated metadata. In order to access data within a company we need to apply a small trick. In the following sample we create a modified data context which points directly to a company:

Now we can start to access the data:

As you can see this approach is very easy and avoids the problem with the manual code generation. If you expose more pages then they are instantly available in your code.

As with the Wsdl type provider you can expose the generated types from this F# project for use in C# projects.

Further information:

• Walkthrough: Accessing an OData Service by Using Type Providers (F#)
• Walkthrough: Creating and Interacting with a Page Web Service (OData)

If you are a Dynamics NAV developer you have probably heared of the web services feature which comes with the 2009 version. In this walkthrough you can learn how to create and consume a Codeunit Web Service. This method works very well if you only need to create the C# proxy classes once. If you have more than one developer, an automated build system, changing web services or many web services then you will come to a point where this code generation system is very difficult to handle.

Microsoft Visual F# 3.0 comes with feature called “type providers” that helps to simplify your life in such a situation. For the case of WCF the Wsdl type provider allows us to automate the proxy generation. Let’s see how this works.

Web service generation

In the first step we create the Dynamics NAV 2009 Codeunit web service in exactly the same way as in the MSDN walkthrough.

Connecting to the web service

Now we create a new F# console project (.NET 4.0 or 4.5) in Visual Studio 2012 and add references to FSharp.Data.TypeProviders, System.Runtime.Serialization and System.ServiceModel. After this we are ready to use the Wsdl type provider:

At this point the type provider creates the proxy classes in the background – no “add web reference” dialog is needed. The only thing we need to do is configuring the access security and consume the webservice:

Access from C#

This is so much easier than the C# version from the walkthrough. But if you want you can still access the provided types from C#. Just add a new C# project to the solution and reference the F# project. In the F# project rename Program.fs to Services.fs and expose the service via a new function:

In the C# project you can now access the service like this:

Changing the service

Now let’s see what happens if we change the service. Go to the Letters Codeunit in Dynamics NAV 2009 and add a second parameter (allLetters:Boolean) to the Capitalize method. After saving the Codeunit go back to the C# project and try to compile it again. As you can see the changes are directly reflected as a compile error.

In the next blog post I will show you how you can easily access a Dynamics NAV 2013 OData feed from F#.

After the official Visual Studio 2012 launch yesterday I think it’s a good idea to announce two new type providers which are based on the DGMLTypeProvider from the F# 3.0 Sample Pack.

Synchronous and asynchronous state machine

The first one is only a small extension to the DGMLTypeProvider by Tao. which allows to generate state machines from DGML files. The extension is simply that you can choose between the original async state machine and a synchronous version, which allows easier testing.

If you want the async version, which performs all state transitions asynchronously, you only have to write AsyncStateMachine instead of StateMachine.

State machine as a network of types

The generated state machine performs only valid state transitions, but we can go one step further and model the state transitions as compile time restrictions:

As you can see the compiler knows that we are in State2 and allows only the transitions to State3 and State4.

If you write labels on the edges of the graph the type provider will generate the method names based on the edge label. In the following sample I’ve created a small finite-state machine which allows to check a binary number if it has an even or odd number of zeros:

As you can see in this case the compiler has already calculated that 10100 has an odd number of zeros – no need to run the test .

This stuff is already part of the FSharpx.TypeProviders.Graph package on nuget so please check it out and give feedback.

In the last post I wrote about the PersistentVector which I ported from Clojure to .NET. It’s implemented as an immutable hash array mapped trie which optimizes the constant factors so that we can assume O(1) for count, nth, conj, assocN, peek and pop.

But for some applications Rich Hickey shows us that we can optimize the constant factors even further. If we are sure that we are only holding exactly one reference to the vector than we can mutate the underlying representation instead of copying the arrays on every change. This idea is implemented in the TransientVector which I also ported from Clojure.Core to FSharpx.

Let’s look at a small example. Here we want to convert a collection to a PersistentVector:

As you can see we iterate over the collection and conj the items to the current PersistentVector. But in every step we forget the reference to the last version. This is exactly the point where can use TransientVector:

Here are the results:

Most higher-order functions on vectors like map are also implemented with this trick.

Rich Hickey created a very nice set of persistent collections for Clojure. I started to port them to FSharpx and today I want to present the PersistentVector. The basic idea is that we want to have something like an array but immutable.

Vectors (IPersistentVector)

A Vector is a collection of values indexed by contiguous integers. Vectors support access to items by index in log32N hops. count is O(1). conj puts the item at the end of the vector.
     From http://clojure.org/data_structures

These vectors are very fast in practical applications since the depth of the underlying tree is not greater than 7. First performance tests show the following on my machine:

These results are not that far away from the Clojure/Java implementation (see below). The lookup seems to be a bit faster but assoc is slower. Maybe that has something to do with the internal array copy function of .NET:

After installing the FSharpx nuget package can use this Vector<T> from C# like this:

More samples can be found in the PersistentVectorTest.fs file.

Additional resources:

• Original implementation
• Data structures in Clojure
• Rich Hickey on "Persistent Data Structures and Managed References"
• Understanding Clojure’s PersistentVector implementation
• Hash array mapped trie

F# 3.0 brings the new type providers feature which enables a lot of different applications. Today I’m happy to announce that the FSharpx project brings you a WPF designer for F# in the Visual Studio 11 beta.

A big kudos to Johann Deneux for writing the underlying XAML type provider.

1. Create a new F# 3.0 Console application project
2. Set the output type to “Windows Application” in the project settings
3. Use nuget and install-package FSharpx.TypeProviders.Xaml
4. Add references to WindowsBase.dll, PresentationFramework.dll, System.Xaml.dll and PresentationCore.dll
5. Add a Xaml file to your project. Something like this:
6. Now you can access the Xaml in a typed way:
7. Start the project

Enjoy!

BTW: No code generation needed is for this. No more nasty *.xaml.cs files.
BTW2: Try to change the name of Button1 in the Xaml and press save.