Business Central Development

When you spend more time in C# than C/AL, and you still tell yourself and the world around you that you are developing for NAV, then this post is for you. I already wrote a three-article series about “DLL hell” and how to resolve it, and in my last post in the series (…

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.

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

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.

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,…

Ancient wisdom goes that you cannot have more than one write transaction going on at the same time in a single session in NAV. This is absolutely true, in and out. Some features, like Activity Log , will leave you wanting to be able to write to the database outside of the normally running transaction.

Today at NAV TechDays 2015 in Antwerp, I attended a presentation by Nikola Kukrika, Ciprian Iordache, and Gary Winter, at which Ciprian presented a new design pattern based on a new feature in NAV 2016: Activity Log.

Microsoft Dynamics NAV 2016 brings many new features, one of which is a set of PowerShell cmdlets to manage add-ins. These are: New-NAVAddIn Get-NAVAddIn Set-NAVAddIn Remove-NAVAddIn While these cmdlets are certainly useful for installation and deployment, I find them even more useful during development.

[Update, February 8, 2016: there is a new version of code from this post. Please check https://vjeko.com/dynamically-loading-assemblies-at-runtime ] Okay here we go. In this post I deliver the promised code that handles automatic deployment of all your assemblies to client and server, as needed.

Deploying .NET assemblies to clients and servers in need is no simple affair. In my last post I have explained the problem, and announced the solution. As promised, in this post I bring you the solution. To be fully honest, this post only brings the conceptual solution, just a little brain game for you to train your .NET brain muscles a bit.