A few thoughts around assembly naming and versioning for NAV

  • Post comments:3 Comments
  • Reading time:5 mins read

Are you developing .NET assemblies intended to be used from C/AL? If so, then you must have realized that keeping proper track of them and managing them on the server (or client, in case you still do that) is not a simple affair.

Assemblies in .NET are identified through their fully qualified name, and that’s how NAV tells one assembly from another, as well. Fully qualified name contains the assembly name, version, public key token, and culture information. A good practice in .NET development is that when you update assembly’s functionality, you also version that assembly up, essentially resulting in a completely new assembly, which doesn’t have the same fully qualified name as the older version did.

However, this kind of change is a breaking change. In .NET, it’s not all that breaking – you simply reference the new version and this applies to whole project. Or whole solution, depending on how you configure the MSBuild behavior.

But in NAV, it’s a completely different story. Versioning an assembly up is a very breaking change. In NAV, we cannot simply replace a reference once, and then have it apply to the whole database. Unfortunately, we have to update a reference on every single variable, and if you ever had to do it, chances are you don’t keep any happy memories about this experience.

That’s why NAV developers, when working in .NET, prefer not versioning up. And that’s wrong.

(more…)

Continue ReadingA few thoughts around assembly naming and versioning for NAV

Getting out of the DateTime mess, or how to get Utc DateTime in C/AL

  • Post comments:13 Comments
  • Reading time:5 mins read

Today at work I was trying to untangle one big bowl of spaghetti called DateTime. It’s the C/AL DateTime I am talking about, not System.DateTime from .NET.

The problem with C/AL DateTime is that no matter what you do it’s, according to documentation, “always displayed as local time”.

Another problem with C/AL DateTime is that C/AL is a bit rude when it comes to System.DateTime: whenever C/AL compiler (or runtime) encounters a value of System.DateTime it’s automatically converted to C/AL DateTime.

When you combine those two problems, you get the following problem: even though System.DateTime is perfectly capable of handling time in both UTC or local kind, C/AL isn’t.

To prove this point, just run this:

MESSAGE(‘Current local time: %1\Current UTC time: %2’,SystemDateTime.Now,SystemDateTime.UtcNow);

It will show this:

image

And I am currently sitting in a UTC+1 time zone, mind you.

(more…)

Continue ReadingGetting out of the DateTime mess, or how to get Utc DateTime in C/AL

Visual Studio Control Add-in Project Template

  • Post comments:23 Comments
  • Reading time:3 mins read

If part of your daily job includes creating control add-ins for Microsoft Dynamics NAV, then you know that creating control add-ins that target all clients requires quite a lot manual work. There are a lot of small steps that you must do every time.

To avoid all that work that adds no value, only frustration, here’s a Visual Studio project template that you can use to automate the process of creating a new control add-in.

(more…)

Continue ReadingVisual Studio Control Add-in Project Template

Deploying from Visual Studio, update

  • Post comments:1 Comment
  • Reading time:3 mins read

A few days ago I have published my PowerShell script that streamlines and automates deployment of control add-ins from Visual Studio. Over the past couple of days I have improved it a little bit, and fixed a few bugs, so here’s an updated version that is more resilient to your project structure, produces resource zips that NST not only extracts, but actually understands, and does a little more.

(more…)

Continue ReadingDeploying from Visual Studio, update