Category Archives: C#

Dynamics NAV in C# | Part 2 | Classes (Continued)

Disclaimer (Repeated): If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

In my last blogpost I talked about interpreting the table object in NAV as a C# class, how to use C# properties as fields and how to use C# methods as function that then map to another C# class which represents a codeunit.

The example code allowed us to create a Customer using Number Series and Format the Address.

Let’s take this one step further to really explain how this mapping is done, and how to use some of these OOP concepts back in our beloved Dynamics NAV C/AL

Sales Header

Let’s create a new class to create a Sales Header. The goal is to post the document as a Sales Invoice, we will reuse the Customer and FormatAddress classes.


There are a couple of things I’d like to discuss in this example. It might not be the official way to do it in C#, but the idea is to be able to pass a customer class to the sales header and populate the name and the address. I also want the Order Date to be the Posting Date unless the order date is set to a different value. For the latter I probably need to add some more code like Jason shared on part I of this post.

So let’s see what happens if we create a new Sales Header like this:

2014-11-29_11-55-08In the example above we first create the customer like in the first post, then we create a new sales header and “Validate” the Customer. This populates the Name and the Address. Then we set the Posting Date, which sets the Order Date. We write the values to the console to see that it works.


Let’s repeat using a codeunit as a method and post the Sales Header to a Sales Invoice. To do this, we need the SalesPost  class that we make a method on the SalesHeader class. Like this:


If you would have to fully design this in C#, you would probably use inheritence and try to reuse more elements, but we are trying to map C/AL to C# using the methodology we are used to in C/AL.

So we create a new C# class SalesInvoice which is a subset of the Sales Header, like table 36 and 112 in Dynamics NAV. In the SalesPost class we convert a SalesHeader into a SalesInvoice.

I’ve explored if something like TRANSFERFIELDS exist in C# and found a class on GitHub but decided not to use it for simplicity reasons.

If we use this in our example it would look something like the following:


So we “Post” the Sales Header to a Sales Invoice and print the Customer Name to prove it works.

Let’s take it one step further…

To complete the class lesson, let’s reuse the FormatAddress on the Sales Invoice, like we would do in Dynamics NAV. In the first part of this post you’ve already seen that I had a function in my FormatAddress class that takes the Sales Invoice as a parameter.

Let’s use this, and again, we would make FormatAddress a method on the Sales Invoice class.


You probably get the point now so let’s see what this does:


So to briefly recap, we create a customer class and populate the address. We “Validate” that into the Sales Header and “Post” it into the Sales Invoice. Then we Format the Address.


The idea of this post is to explain C# from a C/AL perspective using names you recognise. A table is a class, A codeunit is a method and A field is a property.

There are probably very smart things you can do in C# to acomplish the same in a more object oriented approach. Personally I like the NAV model since it’s self explaining and simple.

This is what makes NAV rock!

Next episode: Plymorphism in Dynamics NAV. (I hope :).)

Dynamics NAV in C# | Part 2 | Classes (Updated)

Disclaimer: If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

UPDATE (29/nov/2014): Based on the feedback from Jason Down I changed the C# code to get the number from the number series class.

Ok, there we go. No more conferences so time to do some actual blogging.

This is part 2 of my NAV in C# series. If you have not done so, please read part 1.

In this episode we will talk about classes.

In C# a class is very powerfull. It’s a datatype that you can form yourself giving it properties and methods. And since C# is object oriented, you can inherit from classes etc.

But let’s not get into these details. The blog series is intended to explain C# from a Dynamics NAV perspective.

So how do we map a class to Dynamics NAV.

Actually you could see a table or a codeunit as a class.

A Table is a Class

Let’s start with that. Let’s have a look at the customer table in NAV. It has a bunch of fields


So how would something like that look like in C#:


Each field is a property. You can see that it is a property because it has the { get; set; } syntax

If you would like to code against it you would declare a new customer like this

Customer Cust = new Customer();

Cust.Name = “Mark Brummel”;

Cust.Address = “Somewhere”;

This would create a new instance of the class and populate the name

Number Series

But we have number series in NAV.  So let’s make that

A Codeunit as a class

Let’s make a class that can return number series.


This is a very simple class with a method that returns a number. It should be smarter but I hope it explains the idea

Return the number in the customer

So what if we want to assign this number to the customer? In C/AL we would have triggers. In this example we would use the getter, and store the value in a variable. This latter would off-course be done in the SQL Table in NAV itsself.


In the property we return the value of the number series. See how easy that is?

Now if we create a sample application that would create a customer we would have this


So we have a new customer with a number, that we do not declare in the class, it is automatically added, like in Dynamics NAV

What about address formatting

So we print the address, but what if I want to do that like in NAV? Then we need a new codeunit class, and we would add a method to the class, like this:


This class takes a customer as a parameter and calls into a generic function to move the address to an array. It also has a function for the Sales Invoice, a class we will use in the next blog post.

A Codeunit is a Method

In C# we would add the adressformating as a method that we can do with a class. This way we don’t have to call the addressformatting class in our programm.

Like this:


And the keyword this stands for what we would cal Rec in Dynamics NAV.

This is what it does in the program:


A Table is a Class, A Codeunit is a Method (and a class)

So a table definition (not the actual SQL table) would be a class and a codeunit too, and added to the table class.

This actually would work nice in NAV too, if we would declare things like FormatAddress on the table, we would never have to use Codeunits as a variable anymore.

Next time…

I will explain how to create a sales order in C# and how to post it to a sales invoice.

Hang on, stay tuned.

Dynamics NAV & GIT

In this post I introduced Visual Studio Online as a tool to do source control for Dynamics NAV.

Another option is to use GIT. Visual Studio also conects to GIT and many developers love it.

It looks a lot less sexy than VSO but it is extremely powerfull and command line based. Try it out, it is fun.

Kamil Sazec, a good friend and NAV MVP has publised a script on codeplex for using GIT and NAV.

Here is what he says on his blog:

PowerShell–Strong tool for MS Dynamics NAV Developers

After long time, I have found some time to write this article.

Last few months was full of “Crete” testing including the PowerShell scripts to merge NAV Objects. And I must say, I have started to love PowerShell. Things, you needed to do manually or you needed to use some “hack” to do automatically (like using ROT), you can do now using PowerShell. And I started to create some scripts for things, I just needed actually do. You can find the scripts on the NAVScripts codeplex project, which is open for you and if you want, you can contribute. I want to have this project to store different scripts “made by NAV developers for NAV developers”.

Actually you can find these scripts there:


this script takes two branches in GIT repository and merge the objects in them. You can solve the conflicts in kdiff3 or araxis merge (or any other tool if you want). This way you can “work around” standard GIT merge mechanism. I have merged the Rollup Update 9 to our Addon database in just 5 minutes! Merge of the updated addon to our customer customized database – another 3 minutes of work! In this way, you get the nice “train station plan” (my internal naming) like this:



another script, which you can use after you merge the objects. This script is doing these steps for you automatically:

  1. Create new NAV database from .BAK file (e.g. from Cronus demo db backup)
  2. Create new NST instance for this database
  3. Import NAV license to the server (to have enough permissions to create objects etc.)
  4. Import selected .FOB file to the database (e.g. FOB with latest Rollup Update to update the database objects)
  5. Import selected .txt files to the database one by one (to see where is problem)
  6. Compile the objects imported in step 5 one by one (you can see the problems)
  7. Run NAV client for manual check of possible problems (could be skipped, could send email to you when ready for manual check)
  8. Export all objects to .FOB file
  9. Remove NST
  10. Drop database

As you can see, result should be FOB file with compiled objects ready for import to target database. It is something like “Automatic build process”. You can easily add part to run automatic testing…


Other functions

In the scripts there are many functions you can use for own scripts. You can export/import/compile objects to e.g. update the files in repository, update you database from the repository, merge version lists etc.


I hope that you will find these scripts usefull and you will be able to extend them as you will need. All is available from the codeplex here:

You can even fork/clone the GIT repository and contribute… Mrkající veselý obličej


Every NAV developer should learn powershell, because it could save big chunk of time for us. And with the accent to the up-to-date customers, we will need to press the upgrade cost down. And you cannot do that without automating the upgrade process. Correctly written scripts are good tool to do your work. They will never replace you, because still there are exceptions which needs some human brain to solve, but it is not 100% of the process now, but e.g. 10%.

Merge of our new version of addon to some customer database was 1-2 days in some cases. Now, with the script support, it is just 2-3 hours, in which the 1.5-2.5 hours are automatized and only 0.5 hour is “conflict solving”.

You can find many sources for beginning with powershell, but one for all:

Dynamics NAV in C# | Part 1 | The Differences

Ok, when you make a promise you have to keep it, so here is the first article around C# and Dynamics NAV.

The story is around my own explorations around C#, Visual Studio and .Net.

Before you start working on C# as a Dynamics NAV developer, or as some call us Dinosaur, you need to be aware of the differences in approach.

Database driven development

In Dynamics NAV we are used to develop in a “database”. This used to be a native “fdb” file in the old days and nowadays it’s a SQL Server database. The development we do is a combination of coding and defining metadata.

More than one developer can work in the same database and we can move parts of our code from one system to another using binary files we call “fob”.

File driven development

When working on a piece of C# code in Visual Studio you’ll probably work in what they call a “project” or “solution”. This is usually a folder somewhere on your drive with a bunch of files. To start working on a solution you have to open the “.sln” file which will give visual studio the information it needs. In the simples scenario where you develop a piece of C# code for Dynamics NAV your solution will have a “.cs” file that contains the actual C# code. You can compare this file to a Code Unit in Dyanamics NAV. Visual Studio will also generate a bunch of other files that you can ignore for now


Compiling in Dynamics NAV is called Build in Visual Studio. Both features check the code for errors and generate “stuff”. The stuff in Dynamics NAV is (funny enough) generating the C# from the C/AL and binding it into the other objects. The stuff in Visual Studio is generating the DLL file that you will use in Dynamics NAV as a DotNet library.


Both Dynamics NAV and Visual Studio do not offer object versioning by default.

Team Foundation Server

When working together on a larger Visual Studio C# project you can use TFS, or Visual Studio Online to manage tasks and versions of your C# files.

TFS is text based, like Visual Studio and does not understand the structure of Dynamics NAV and its binary objects that are stored in a SQL Server Database.

You can use TFS manually with the Text files you can export from Dynamics NAV, but there is no automatic interface. There are some third party tools that provide help with that.

Let’s get started: “Hello World”

So having explained the differences, let’s start working on a very simple C# project. We will start with a good old “Console Project”.

After having started Visual Studio we will generate a new project like this:


And then we get “the list” that confuses most people that get started with Visual Studio and makes you unsure.


Lets discuss what we see here

On the right there is a bunch of templates. Ignore everything you see here and only go to Visual C# and Windows. Within this menu we have three types of projects that we will use in this series: Console Application, Windows Forms Application and Class Library. We will now choose “Console Application”.

On top we can choose the version of DotNet we want to use. Dynamics NAV uses 4.5 so we know that our users will have that installed and can go ahead and use this version.

Then we can select a name and location for our project. We choose “Hello World” and leave the folder to default.

On the far right bottom you can see the “golden” option “Add to source control” which will register the solution on TFS or Visual Studio Online system. We will not do that for this example.

The “main” function

When Visual Studio has generated the project we get this window:


Let’s talk through them

First we see a bunch of “using” lines. These are the DotNet libraries that will be used by this project, which can be compared by using Code Units in Dynamics NAV that contain functions you use accross the application, if you don’t define the Code Unit you cannot use the function. We’ll get back to that later in the series.

Then we see the namespace of our project. You can compare this to the Add-On number bands in Dynamics NAV, every project or customer get’s their own Namespace. During our series we will not change the namespaces, just leave it as it is.

Within the namespace we see a class. This can be compared to a object in Dynamics NAV, a logical group of code or features. You can put everything in one class like in a Code Unit but that would not be maintainable

Lastly we see what is most important

static void Main(string[] args)

This is a function. It is very important to understand the syntax of a function. Unlike Dynamics NAV where we define functions as metadata we can define functions in C# by just typing in new text. We can break down this line into four parts


This defines how the function can be used. We will need this when we start working on DLL files that we use in NAV. Functions can be Static, Public Private. Comparable to using local functions in Dynamics NAV or Single Instance codeunits.


This is the return value. Void means no return value. Like Dynamics NAV a function can only have one return value


This is the function name. Main is a reserved name that can be compared with Codeunit 1 in Dynamics NAV. The program starts here and always passes this code.

(string[] args)

These are the parameters of the function. In this case the function accepts an array ([] means array) of strings.

Hello World

Now that we know what we see here we can add some code to our function Main and test if it runs.

Since we have a console application we can write to the console. Lets add these lines:



Console is a variable we can use like DIALOG in Dynamics NAV. This will display “Hello World” and wait for user input.


Please note that even though we are not passing values to the ReadKey we still have to provide the (). When you start writing C# this will make you go bananas and if you forget them you get a really weird error like this:


So never forget them!

Let’s run the thing alright!


This is what you get when you press the Start button.

Congratulations you have just created your very first C# application and learned about a lot of differences between Dynamics NAV and Visual Studio.


Dynamics NAV is moving to C#, get ready to follow!

Ok, maybe the title is not to nice, but hey, I got your attention.

Since the introduction of the Three tier environment, Dynamics NAV runs on C#. In the first versions it was hidden and closed, but with the intoduction of DotNet interoperability it is possible to move bigger pieces of business logic from C/AL to C#.


On top of that, the world is asking, no demanding, more integration between applications. Webservices are the standard of doing that. When consuming webservices in Dynamics NAV, you end up writing C# code very fast.

In the last six months or so I spend a large amount of my time writing C# code. This started with interfacing and consuming webservices. But getting the hang of this thing, I started doing more with C#. The possibilities are endless.

I wanted to spend some blog articles on my journey exploring C# as a C/AL developer. There are some fundamentals you should understand which will make life a lot easier. Plan is to start these entries end of summer and contintue during fall.

So DotNet interop allows you to start using C# for business logic, but one of the questions is should you. C/AL is more or less open source and C# will get compiled, debugging is harder and so is managing your code.

Part of the examples I plan to write are not even using C#, you can do a lot of cool stuff just using standard DotNet libraries which means you do not leave C/AL.

Should NAV move to C#

This is an ever returning question and to answer it, you must understand C# and C/AL. C/AL programming is based on binary objects which get converted to text if you open the code whilst C# is text based programming.

Dynamics NAV has 1000ds of C/AL objects which are manageable because we have object designer and object numbering, Visual Studio works with projects and files. Imagine NAV as a project and browsing 1000nds of .cs files in the Visual Studio project window. Even if Visual Studio could understand C/AL we would need a smart way to browse through objects.

Visual Studio is also not used to multiple programmers working on the same “objects” eg. database. If you use Visual Studio online you can make local copies of projects which are later merged together, automatically if possible.

Then there are the typical NAV commands of which talking at the database is the biggest challenge. For most developers it will not be a big issue to move to C# syntax with its {} structures, this is easy to get used to. A bigger challenge would be to make C# aware of SETRANGE and FINDSET. It does not know these commands. You would need function libraries that understand this syntax.


What if it did? What if you could write C/AL commands like SETRANGE and FINDSET in C# and then use all the possibilities C# has and C/AL does not have, would that be great? Or would that take away “simplicity”?

React! Leave you opinion!

During the next months I will be going through what I learned in C# and I am still learning. The journey is so extremely cool, C# has so many great features that will let your creativity go bananas.

What do you think?

Are you ready to move to C#?

Ready to Move Cardboard Box Moving Relocation

Visual Studio Online | Welcome Cloud Development

It was not until recently that I was introduced to the term ALM. Application Lifecycle management. No idea when this Three Letter Abbreviation was invented but the problem it describes are much older, and familiar to a lot of Dynamics NAV developers.

About three years ago I wrote this article, that caused quite some stirr in the NAV Channel, unintended, but typical for our community I think.

So what is the problem definition.

Keeping track of Development History. Why did What happen and When.

After writing the article I dropped the subject. We started the Partner Ready Software initiative and ALM is/was not part of our initial primairy focus. When presenting our vision on Dynamics NAV development I use these slides:


What we tried…


What we need…

And from a pure software quality concept this is true.

But that does not take away the fact that ALM is quite cool too. And a recent development caught my attention that might be of interest to all Dynamics Partners, but especially the smaller ones or the ones who still do customer based development.

Until recently TFS had to be installed on premisse and it is “something to maintain” for IT guys.

When Waldo and I were in Redmond (WA) last year for MVP Summit I went to a session about ALM where Visual Studio Online was presented, as Luc van Vugt also mentions in one of his posts.

On first thoughts you might think this allows you to code C# in the cloud, and yes, you can do that if you want. But a better naming would be TFS Online since it allows a Team Foundation Server to run in the Cloud for free without any hassle or cost. How cool is that!

This is definately something that brings ALM back into my area’s of interest and I have already spent some time exploring it.

You can setup different projects in the tool and it allows you to define work items and sprints to work scrum. You can define team members and do planning and even do visual kanban planning. Really super cool!

The first downside I found is that it is still required to use an on site tool to check in and check out objects. You can use Team Exporer which is free.


But TFS also allows you to use PowerShell to check in and check out objects which means it can be integrated with existing Dynamics NAV PowerShell scripts. This would be very interesting to NAV Partners and we won’t need all these third party tools to integrate.


GIT & Microsft Dynamics NAV

Another concept that I stumbled on while exploring VSO is GIT. I am not quite sure yet how to combine these two concepts in NAV but the way I look at it is that GIT helps while doing development and work is still unfinished, and when you check in objects in TFS they are ready to be tested.

TFS is integrated with GIT and I am going to spend some time investigating what the options are and how they can work together.