Monthly Archives: August 2014

NAV 2013 R2 | Debugger Watches

I totaly love the concept of pages. They are easier to merge and upgrade and they way they render is awesome. However, they come with a few drawbacks. Some of them we already had in the classic client with forms, some are new.

One of the drawbacks is the lack of drag and drop. This was true for the classic client too.

A place in Dynamics NAV where it is very obvious what would be the value of drag and drop is the debugger. The debugger in NAV2013(R2) is designed as a page.

Like this:


In general it works pretty good. It is easier to break, toggle breakpoints and the fact that you can debug any user on the servicetier is just straigt from heaven.

But one of the things that was a 1000 times easier in the old debugger was watches. It is no longer possible to just drag and drop them.

However… I only recently found a neat trick and I figured “how is it that I did not notice this earlier”.

The AL codepart is developped as a client add-in which allows to send events to the page. One of the events is adding a watch while hovering over a variable like this:


Now take a close look at the icon


If you push the + sign the variable is added to the watchlist.

Personally I find myself pretty foolish not noticing it for more than like 2 or 3 years but hey, I might not be the only one.

Here is the event in AL:




Design Patterns | 10 Video’s

At the moment of writing this, 10 Design Pattern video’s are published. I recently started working on 5 more.

People at Microsoft have asked me what is the logical order of watching them. This is actually quite a hard question to answer. Some videos are in detail about a specific pattern that is represented by a few fields and some code while other video’s are about larger patterns such as explaining the locial flow of posting routines.

But let’s do a suggestions:

How Do I :

1. Build solutions using design patterns

2. Read and Understand the Posting Routines

3. Work with Master Data and Posting

4. Implement Master Data

5. Implement the Number Series Pattern

6. Use the Journal Template-Batch-Line Pattern

7. Implement the Singleton Table Pattern

8. Use the Select Pattern in a Posting Routine

9. Use Temporary Datasets

10. Use the Transfer Custom Fields Design Pattern

I hope this helps you find your way. The five new titles will be published soon.3. 3.

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

Dynamics NAV Events | Fall 2014

It is august 2014 which means that most people who go on vacation in the summer period are either just returning or maybe still enjoying their well deserved rest. At least I did for two weeks in Interlaken this year.

Is also means we are at the verge of the new event and release season which is each fall since the last few years.

NAV2015 will be released this year and I am very exited about the new features that will be shipped this version.

I will be attending and speaking at four out of five events.

1. Directions USA | San Diego

The first event is Directions USA in San Diego, from September 14th to 16th. I always enjoy Directions USA since the atmosphere feels nicer than in europe or at least that is my opinion. It is also the event where most of the Liberty Grove associates get together and meet each year.


2. Directions EMEA | Poznan (Poland)

Each year EMEA and US switch in priority and this year EMEA is second after USA. Poznan Poland this year. The contents of the events is more or less the same.

The event is from October 8th – 10th.

MVP Track

This year is the first year that there is a dedicated MVP Track where 10 sessions are hosted my MVP’s. The track is lead by Gary Winter, a new MVP since this year and part of the Partner Ready Software team. I will be doing a session about designing MiniApp applications in Dynamics NAV.

3. NAVUG | St. Louis

Attending NAVUG summit was on my bucket list for many years and this year I will be representing Liberty Grove and presenting.

I do a lot of work for US customers and look forward to meeting some of them in real person. The event dates are October 14th to 17th.


4. NAVTechDays | Antwerp

I must admit my favorite, at least from a content perspective. This event is hosted in a cinema with huge screens and fantastic seats.

Partner Ready Software will be presenting this year again and we hope to bring you some new and fresh ideas as you are used to from us.

The event is in November from 20th to 21st.


Pre-Conference workshops

Like last year there are pre-conference workshops. Together with Gary Winter I will be hosting a Partner Ready Software workshop again. There is still room available so book your seats fast.


And then…

So the question is what is the 5th event and why am I not there.

In November there is also Convergence EMEA in Barcelona. Unfortunately at the same time you have MVP Summit in Redmond. Since the latter is more interesting from my own development I choose to attend this and enjoy three days of inside Microsoft information.

Hope to see you in person at one of the events!