On-Premise Extensions & Customer Licenses

Original URL…

On my task list for one of my customers was a nicely isolated module that I could make into an extension.

I’m a huge fan of making many small extensions rather than trying to put all of one customers modifications in one project.

In this case it is a side-by-side project with C/Side so I have created my own app file for the packages. I’ll see if I can blog somewhat about that later.

Extensions are not just for AppSource

Some people seem to think that on-premise we can just as well continue to use C/Side and even though I am a huge C/Side fan I have to disagree.

On-Premise extensions have a lot of value, especially because extensions enforce discipline.

The Caveat

The biggest challenge that I face when programming bespoke Extensions On-Premise is the deployment. Microsoft has made the testing of the license very strickt. In fact, it is more strickt than the runtime check which in my opinion is a bug. Microsoft however has a different opinion. Business Central in fall with the new license model solves it because then, there is no more license.

Temporary Tables

Everyone who has attended my Programming Master Class (800 of you) knows that using Temporary Tables as containers of code are one of the most powerful assets for clean code and reducing code cloning.

The Table behaves as a class with methods and properties and actually replaces the need for Code Units completely. Well, almost.

Using these tables in C/Side is free. It has always been free. End Users only have to pay for tables in their licenses if they write data to the database.

When you ship an extension with a table object that is outside of the customers license you’ll get an error message. The publishing process does not check your code for actual inserts and it probably could not even do that if they wanted to.

In C/Side end-users can import objects with a fob file that are outside of their license.

PowerShell to the Rescue

I’ve created a small PowerShell script that temporarily changes the license at the End-User and later switches it back. There is a lot of clean up to do but for me it was a huge time saver.

My plan is to somehow make this PowerShell script run directly from Visual Studio Code and launch the Windows Client instead of the Web Client.

Please not that I don’t dislike the Web Client but we have some pages in our solution that not yet render perfectly and have to be replaced first with another solution (probably Angular w. DevExpress).

Here is the script.

Don’t expect rocket science. I try to keep my PowerShell understandable.

Set-ExecutionPolicy unrestricted

import-module "C:\Program Files (x86)\Microsoft Dynamics NAV\110\RoleTailored Client\NavModelTools.ps1"
import-module "C:\Program Files\Microsoft Dynamics NAV\110\Service\NavAdminTool.ps1"

$ServiceTier = "2018DEV"
$Version = ""
$xVersion = ""
$AppFolder = "\\DynamicsNAV\Extensions\Performance\Version\"
$AppSource = "\\DynamicsNAV\Extensions\Performance\Source\"
$AppFile = "Mark Brummel_Performance_" + $Version + ".app"
$AppName = "Performance"

#Get-NAVAppInfo -ServerInstance $ServiceTier

Move-Item -Path $AppSource$AppFile -Destination $AppFolder$AppFile -Force -ErrorAction Ignore

Import-NAVServerLicense -LicenseFile "\\License\Development.flf" -ServerInstance $ServiceTier
Restart-NAVServerInstance -ServerInstance $ServiceTier

Uninstall-NAVApp -ServerInstance $ServiceTier -Name $AppName -Version $xVersion
Unpublish-NAVApp -ServerInstance $ServiceTier -Name $AppName
Publish-NAVApp -ServerInstance $ServiceTier -Path "$AppFolder$AppFile" -SkipVerification
Install-NAVApp -ServerInstance $ServiceTier -Name $AppName -Version $Version

Import-NAVServerLicense -LicenseFile "\\License\Customer.flf" -ServerInstance $ServiceTier
Restart-NAVServerInstance -ServerInstance $ServiceTier

#Sync-NAVApp -ServerInstance $ServiceTier -Name $AppName -Mode Clean -Force
#Sync-NAVApp -ServerInstance $ServiceTier -Name $AppName -Mode Add

The bottom two commands are commented out. I use them when I make schema changes to avoid having to create upgrade codeunits during the development process.

The Version and xVersion are because I like to keep some old versions of the .app file while I do the development. The UnInstall and UnPublish is not required if you increase the build number with each build

A tip to Microsoft would be to implement some of the old C/Side code into the Extensions module that only deleted data/colums for those tables/columns that were really changed.


Visual Code AL without Full Dev license.

Original URL…

Designing with customer regular license.

I was thinking about difficulties to teach NAV design to final customers without full developing license. Most of customer licenses only can develop code in reports and XML ports. They can´t put code into Codeunits, table and pages.

So essentially teaching final customers is create new tables, fields, pages and mainly report builder design. It´s easier to teach customer with full dev license, closer to your daily work and you are not fighting all the sessions with license limits and the absolute not funny fact: you can´t develop business logic.

The test with Visual Studio Code.

We configure in Nav 2018 local machine service with the specifications:

–          No dev full license.

–          Codeunit Objects purchased from 50000 to 50099.

A very common scenario in NAV customer final license.

So, the first test is develop an extension and deploy it pressing F5. The result is:


It failed because an object was out of 50000..50099 range (50150). If I change the number of the extension into available number range, the extension is successfully created.

I also notice, anyway with or without right range, the package can be created.

Conclusion: Customers can develop extensions with their own license, also Codeunits. The only requirement is assign numbers in their purchased range objects (even for tableextensions and pageextensions).

Able doesn´t mean easy. Opinion.

We can expect a crowd of final customers developing Coduenits by themselves……….or may be not.

We can see some difficulties for become this real: C/SIDE was simple and direct, more accessible to people without a strong programming knowledge. VIsual Studio Code is less democratic on that point. It free, but requires programming background.

Also we are all the time in an On-premise scenario and On-premise will not be future mainly scenario.

Object Licensing with Microsoft Dynamics 365 Business Central

Original URL…

My last blog post was about the possibility to create tenant customizations for Dynamics 365 Business Central. That raised some questions about licensing. Which I perfectly understand considering where we come from. With Dynamics NAV on-prem we have to license every single object. A base set of objects like Pages and Reports come for free with Page Designer and Report Designer, but if you want to have extra objects you have to first wire some money to Microsoft. So the question how that works with Dynamics 365 Business Central is a very valid question indeed.

Disclaimer: what I write here is the current status to the best of my knowledge. Microsoft could decide to place restrictions or even completely remove the possibilities. It’s unlikely to happen, but anyway, don’t shoot the messenger…

Dynamics 365 Business Central allows for three different number ranges to create extensions.

Object range Extension type Available in AppSource Available on-premise
50.000–99.999 Tenant customization X
1.000.000–60.000.000 ISV number range X X
70.000.000–75.000.000 Original AppSource number range for Financials X

Tenant Customization

Here we are talking about extensions created in the 50.000 – 99.999 range. Like I explained in my previous post. For those who find it hard to believe that all these objects are just for free: this is similar to the SPLA license which also includes this object range for free.

Extensions created in this number range cannot be published on AppSource. The only way to deploy a tenant customization to Business Central is to upload it through the Extension Management page. These extensions can also be deployed to a on-prem installation, as long as the license includes the objects being used.

ISV number range

An ISV can choose to create an extension in the number range they already have for their on-prem solution. This is the existing number range 1.000.000 – 60.000.000 for ISV’s and it requires an RSPA and CfMD to be free for the ISV. This number range is usable both on-premise and on Business Central.

This comes close to business as usual, right?

So ISV’s could choose to use their existing number range and convert (parts of) their existing solution to an AL extension. This AL extension will then be usable both on-premise and on Business Central. What’s more, it will be possible to publish these extensions as an app on AppSource. That means there is no need to split development between cloud and on-prem.

The pricing and payment can be similar as it is today when delivered directly to an end-customer. But when published on AppSource it is recommended to include monetization options like running in trial mode and integrate with a payment provider.

Please note that at this moment AppSource is not accepting extensions in the ISV range, but it will be implemented soon. Wait for communication from Microsoft about this. However, it should not stop you to start moving your solution to extensions!

AppSource number range

The number range 70.000.000 – 75.000.000 was the original number range for apps for Microsoft Dynamics 365 Finance and Operations, Business Edition (last time I use that in full writing…). This number range remains and should be used for apps that will not be available on on-premise. These apps are ‘born in the cloud’ so to say.

At this moment AppSource doesn’t have a payment process. The app needs to have a built-in payment process. Which is another topic I could talk for hours about…

More information

More information can be found on this landing page: Build Your Business on Dynamics 365 Business Central.

Or directly in these PDF files:

Publishing on AppSource

This is the most preferred way to get an app. Both for the customer and for the ISV. For the customer AppSource is the first place where they can find solutions to extend Business Central for their business. They can trust that these apps have gone through a validation process. A vetting process that checks if the app is designed for Business Central, follows the UI guidelines, has the same end-user experience as the whole application and, last but not least, is backed by a support process.

For the ISV it is important to be on AppSource because it allows them to reach a wider audience. Microsoft will put AppSource in the spotlights and ISV’s get that marketing power for free. Being visible on AppSource also proves the ISV to be trustworthy, it comes with a positive image.

Keep in mind that there is a validation checklist to publish an app AppSource. The linked PDF’s above do have more information about the technical and marketing validation checklist. The technical checklist can also be found here.

Compare the rules for publishing and app on AppSource with the rules for CfMD and you will see a lot of similar requirements. There are also differences of course. For AppSource you don’t go through the CfMD process that is available for on-premise solutions. The rules are tested during the app validation process after you have published the app.

Final remarks

I wouldn’t be surprised if ISV’s and VAR’s are going to ignore AppSource because they think they can continue to do what they do today. Well, technically it is a difference because AL is not exactly the same as C/AL, we all know that. But from a business perspective it looks like they could work with Business Central as they do today with on-premise or private hosting.

But I consider that a wrong approach. It ignores the benefits of AppSource. Partners who do that do not take the opportunity to reach a wider audience. They sell themselves short by ignoring the potential volume they could have.

Another very valid question I got about these mix of extensions: what about naming conflicts? That’s a complex issue if you want to allow conflicting names and solve that silently in the background. The most simple solution is to not allow conflicting names. The same applies to Dynamics NAV, you can’t import a fob file with conflicting names, without manual steps, can you? With extensions it’s the same story, you can’t deploy an extension with an object or field name that already exists. So make sure to use unique names, something that ISV’s are already used to with their solutions.

Update: Dmitry Katson reminded me of the possibility to reserve your prefix / suffix for Dynamics 365. More information can be found here, including an email address to send in your prefix / suffix.

That’s it, I hope this clarifies object licensing with Dynamics 365 Business Central. I would say there are no reasons left to not even try to move your IP to AL extensions and try to get your part of the big pie Microsoft is cooking.

How to Download a Microsoft Dynamics NAV License from CustomerSource

To download a Microsoft Dynamics NAV license file from CustomerSource, follow these steps:

  1. Log in to CustomerSource.
  2. Click My Account
  3. Click Product & Service Summary
  4. Click Registration Keys
  5. Select the desired version in the Request and Display License Keys For Version field.
  6. Click Display License Keys.
  7. On the Request License Keys page, select Download License/Registration Key.
  8. Click Save in the File Download dialog box, select the folder where you want to download the license file to in the Save As dialog box and then click Save.
    Note: Do not open the license key before saving it as this may cause problems when you implement the license file.

Dynamics NAV – SII – Licensing

Electronic VAT information under SII – Suministro Inmediato de Información for Microsoft Dynamics NAV
Refresh your license to access the new objects that are added with this release. More…


This update is provided in the following cumulative updates for the different versions:

    • Cumulative Update 57 for Microsoft Dynamics NAV 2013

    • Cumulative Update 50 for Microsoft Dynamics NAV 2013 R2

    • Cumulative Update 38 for Microsoft Dynamics NAV 2015

    • Cumulative Update 26 for Microsoft Dynamics NAV 2016

    • Cumulative Update 13 for Microsoft Dynamics NAV 2017