Blog

Another NAV TechDays is over, and this one was the best so far. 950 people from all over the world all passionate about NAV and technology and eager to learn and share and discuss the latest in NAV. It was amazing, Luc did a great job again, and I am looking forward to the next year, hoping this conference makes it beyond 1000 attendees.

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.

Let me tell you right away if you need to read this post at all. If you never wrote a single .NET class library intended to be used as a .NET interoperability assembly from C/AL, or if you never ever deployed a .dll file into the Add-ins folder of either Service or RoleTailored Client, then you probably don’t want to read this post.

In my two last posts, I laid out the technical design of the Preview Posting feature, and then showed how to simplify its design to get around the unwanted behavior of TryFunction . One thing is obvious from these posts: Preview Posting wants to simulate posting of a document (or journal) to show what the results would be, but without leaving any actual trace in the database.

In my yesterday’s article about the Preview Posting feature in Microsoft Dynamics NAV 2016 I said there are at least two ways to redesign it to avoid both the unnecessary complication and inherent dangers of the TryFunction feature behavior.

One of great new functional features of Microsoft Dynamics NAV 2016 is preview posting. It allows you to preview all the entries that would result from posting a document or a general journal. Preview posting is not a simple thing. If it was, Microsoft would have delivered it years ago.