Runtime packages for Dynamics 365 Business Central on-premise are not a new concept. If you want to distribute your extensions and protect your intellectual properties at best, with Dynamics 365 Business Central on-premise you can generate runtime packages that don’t contain AL code, but only the final artifacts used by the server at runtime (they’re like an app file without symbols and code).
Another interesting feature of runtime packages is that, when the runtime package is generated on the server, the developer license is checked for permissions to the used extension IDs. Then, the extension in a runtime package can be installed on servers that don’t have a developer license.
By default, debugging a runtime package extension is not possible.
Runtime packages have two main limitations:
- they only work for on-premise installations (no way to use a runtime package online or to submit a runtime package to AppSource)
- they are guaranteed to work only if published to a platform with the same version as the one where they were produced (for example, if you want to publish a runtime package on Business Central 20.1 you need to be sure to create it from a 20.1 platform).
A runtime package for a previously installed extension (here called SD App version 1.0.0.0) can be created with the following Powershell cmdlet:
Get-NAVAppRuntimePackage -ServerInstance YOURSERVERINSTANCE -AppName 'SD App' -Version 1.0.0.0 -Path 'SD App_1.0.0.0_runtime.app'
What about source code protection?
As said before, debugging into a runtime package is not permitted by default because a runtime package does not contain any source code. But there’s a way to include source code also in a runtime package if you really need this.
When you execute the Get-NavAppRuntimePackage cmdlet previously mentioned, you can use the IncludeSourceInPackageFile $true parameter or (alternative that I don’t like) use -ShowMyCode $true parameter.
In the past, using the previously mentioned parameters in the Get-NavAppRuntimePackage cmdlet caused an override of the ShowMyCode setting. This means that when using IncludeSourceInPackageFile $true in cmdlet, also the ShowMyCode parameter in app.json was overwritten and set to true and debugging was automatically enabled.
But what happens now?
Now I think that you know that from version 19 the ShowMyCode parameter is deprecated and you should use the new resourceExposurePolicy parameter for a more granular approach of IP protection in your on-premise installations:
With the new Resource Exposure Policy implementation, the IncludeSourceInPackageFile parameter now only defines if the runtime package contains the source code or not. It has NO EFFECTS on the code exposure. Now the value of the resourceExposurePolicy parameter setted in the original extension’s manifest is what defines the exposure policies also in a runtime package.
What does it mean exactly?
This means that now if you have a runtime package and you want to enable debugging or showing the definitions of objects (symbols) you need to:
- include the source code in the runtime package with IncludeSourceInPackageFile $true
- set the correct resource exposure policy in the app.json file accordingly to what you want to expose in the runtime package.
Please remember this changes, actually are not so clear I think.
Stefano Demiliani 
With the option to include (but not expose) the source code in runtime packages, couldn’t Microsoft theoretically allow us to recompile the runtime package? In other words, couldn’t we then have runtime packages that work for all platform versions (of course starting from the platform and application version as minimum version supported).
It would be great to get rid of that hassle, so I wonder why Microsoft does not (want to) allow that.
What are your thoughts on this?
LikeLike
Yes I think that by adding the source into the runtime package this could be theoretically possible. But runtime package (I’m not a big fan of them) is normally born for ISV that want to fully protect the IP, so also disable debugging or stepping into their code. And in this way there’s only a binary that could not work between versions.
LikeLike