Deployment

Dynamically loading assemblies at runtime

  • Reading time:6 mins read

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 (https://vjeko.com/sorting-out-the-dll-hell-part-3-the-code) I delivered some code that help you take control of your .NET assemblies.

This time, I am delivering an updated solution, one that solves all the problems others, and myself, have encountered in the meantime.

So, fasten the seatbelt, and let’s embark on another .NET interoperability black belt ride.

Continue ReadingDynamically loading assemblies at runtime

Database deployment of add-ins in NAV 2016 is broken, big time

  • Reading time:9 mins read

If you are developing .NET assemblies for use with NAV, then sooner or later you’ll figure out that the new database deployment of add-ins in NAV 2016 is broken.

I’ve just suffered through medieval torture of attempting to have my NAV forget about a database-deployed assembly.

First of all – if you are merely consuming an off-the-shelf assemblies developed by somebody out there, you’ll probably not need to worry at all. However, if you are developing your own assemblies, then sooner or later you’ll find yourself stretched in exactly the same torture rack.

Continue ReadingDatabase deployment of add-ins in NAV 2016 is broken, big time

A few thoughts around assembly naming and versioning for NAV

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

Continue ReadingA few thoughts around assembly naming and versioning for NAV

Deploying from Visual Studio, update

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

Continue ReadingDeploying from Visual Studio, update

Deploying control add-ins during development in NAV 2016

  • Reading time:13 mins read

Microsoft Dynamics NAV 2016 brings many new features, one of which is a set of PowerShell cmdlets to manage add-ins. These are:

While these cmdlets are certainly useful for installation and deployment, I find them even more useful during development. When I blogged about deploying resource files automatically during development some months ago, I showed how you could use PowerShell during build process in Visual Studio to invoke a codeunit that registers control add-ins. Now, in NAV 2016, these tasks are a lot simpler with these new cmdlets.

Continue ReadingDeploying control add-ins during development in NAV 2016

Sorting out the DLL hell, Part 3: The Code

  • Reading time:11 mins read

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

For any of you who haven’t read the last two posts, I am talking about automatically deploying .NET assemblies to clients and server, from the database, on demand, at runtime.

This will be heavy on code, so fasten your seatbelt and brace for impact.

Continue ReadingSorting out the DLL hell, Part 3: The Code

Sorting out the DLL hell, Part 2: The Solution

  • Reading time:4 mins read

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. The actual code I’ll deliver in the next post.

Continue ReadingSorting out the DLL hell, Part 2: The Solution

Sorting out the DLL hell, Part 1: The Problem

  • Reading time:6 mins read

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.

Good, since you are still reading it means that you either deployed your own or somebody else’s .NET stuff into NAV’s client or server’s Add-ins folders. If you ever did so, you probably did not enjoy the experience too much. If you did enjoy the experience, maybe you should not read any further either.

Even better! Since you are still here it means that you didn’t enjoy deploying assemblies. Let me break some good news – all your problems are now gone! And I am not talking NAV 2016, I am talking NAV 2013 and anything newer.

Continue ReadingSorting out the DLL hell, Part 1: The Problem

When Should You Purchase The NAV License?

  • Reading time:5 mins read

Microsoft Partners often postpone the actual purchase of the customer’s NAV license until the project is fairly close to go-live. In the meanwhile, they do the development and the testing on-site (or off-site) using their own partner license.

I’ve heard arguments (or better: excuses) to engage in this practice, and I have a very strong opinion on this. So, when is the right moment to actually purchase the NAV license for your customer?

Well, regardless of the fact that 1) you are contractually obliged to purchase the license for your customer at the first moment they get in touch with the solution (which is fairly early in the project), and the fact that 2) you are violating your licensing agreement with Microsoft if you deploy your partner license on third party’s infrastructure, there is 3) a fairly compelling technical reason why you might never want to even try doing any project work involving customer with your partner license.

Continue ReadingWhen Should You Purchase The NAV License?

2nd rule of agile ERP: deploy gradually

  • Reading time:4 mins read

Eat an elephantHow do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records. Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report. One way or the other.

ERP software is huge. It contains thousands of features potentially touching every single tiniest aspect of your business. Implementing ERP is about introducing change into your company, and change can be evolutionary, or revolutionary. Your pick.

Continue Reading2nd rule of agile ERP: deploy gradually