Just use DotNet

Day by day I am moving closer to DotNet programming in Dynamics NAV. More and more of the things I like to do are more easily solved with DotNet than with native C/AL code.

In most cases I can use the standard DotNet types but in some cases I need to build a small DotNet Class to solve the problem.

An example of this landed on my desk yesterday. A colleague of mine needed to be able to print text to the local label printer. Perhaps this can be solved with a simple report but in this case something more was needed. I asked the Internet – how do I print a text file with c# code. Got some answers and selected the one I liked the most.

Normally I rewrite the c# code with DotNet objects in C/AL but in this case I could not. The reason was that I needed the DotNet objects to be executed on the client side, and using DotNet to print requires an event handler. DotNet events are not supported on the client side so I needed to create a class.

I create a c# Class Project in Visual Studio and can use the code I found with only a few modifications.

[code lang=”csharp”] public class NAVTextFilePrinter
public void PrintText(string printerName, string fontName, float fontSize, string[] linesToPrint)
Font printFont = new Font(fontName, fontSize);
PrintDocument docToPrint = new PrintDocument();
docToPrint.DocumentName = "NAV Text File";
docToPrint.PrinterSettings.PrinterName = printerName;
docToPrint.PrintPage += (s, ev) =>
int count = 0;
float yPos = 0;
float leftMargin = ev.MarginBounds.Left;
float topMargin = ev.MarginBounds.Top;

foreach (string line in linesToPrint)
yPos = topMargin + (count * printFont.GetHeight(ev.Graphics));
ev.Graphics.DrawString(line, printFont, Brushes.Black, leftMargin, yPos, new StringFormat());
ev.HasMorePages = false;

The class is compiled with DotNet 4.5 and added to the Client Add-ins folder. If you are using NAV version 2015 or newer just add it to the Server Add-ins folder.

Using this in NAV is easy


Microsoft.Dynamics.Nav.Client.TextFilePrinter can be downloaded from here.

I like to use DotNet when I am handling text – in general. The DotNet object System.String has a lot of functions that can be useful. Just use

String := String.Copy(NAVString);

and your NAV String can now be handled with all the functionality available with DotNet.  Good example is the Renumbering Tool I created a few months ago.

Another example here – where I need to create all the directory tree leading to the file I need to copy.


One of my favorite is the Global Variable Store Codeunit, where I use the DotNet Dictionary to store variables globally. This can be used to minimize the footprint of your code changes. For example, if you need to pass a new variable to a function and you don’t want to change the function – just store the variable before you call the function and retrieve it inside the function. It is even possible to pass a whole record this way.

Downloadable Global Variable Store Codeunit


Clean up your trail

Boy, have these last months been busy.

Now I am working on a management solution for our cloud offering.  This solution is going to give the control of the services and the tenants to a NAV user interface.  I am running Powershell scripts from NAV (thanks Waldo) and things are looking good so far.

I extended the Powershell functionality to be able to read an XML response like Waldo describes here.

One of the things I need to do is to maintain files for this management solution.  For example a NAVData file, SQL backup file and a NAV license file.  When ever I execute a Powershell script from NAV I write these files to a temporary file path and point Powershell over there.

I can’t be sure that every Powershell execution is a success and I can’t leave the temporary files around.  I must delete them.  The solution in my case is to create a single instance Codeunit and apply a DotNet List object.

I only needed a server version, but with DotNet this can be extended to handle the client side as well.



So, every time I create a temporary file I add the file to a DotNet List.  Even if the execution fails the temporary file is still in the list.  When the execution finishes all the listed temporary files are removed.  If the execution fails then the next successful execution will also remove the previous temporary file.

As you can imagine this type of a Codeunit can be used in many scenarios.  By using DotNet Dictionary it is easy to store parameters with names in one place and retrieve them in another.

For example if you need to add a parameter to a standard function, then adding the parameter to the Dictionary before you execute the function and retrieving it within the function will leave the function footprint unchanged and your customization upgradeable.