Dynamics 365 Business Central (on-premise): Extension for printing external documents

A week ago I wrote a post for answering a question regarding how to print external documents from Microsoft Dynamics NAV. This code is C/AL based and it uses DotNet classes that interacts with the local operating system.

How can this code be translated as Extension for Dynamics 365 Business Central?

For the SaaS version of Dynamics 365 Business Central, this is actually not possible. We can’t use DotNet objects in the cloud. But what about the future on-premise version?

This is currently in preview (so you don’t find this feature in your standard sandbox environment) but starting from build 13.0.22895.0 you can call .NET types from AL code if you’re targeting an on-premise deployment.

To use a .NET type in AL, you need to start by declaring a dotnet package:

dotnet 
{ 

}

then you add a declaration of the assembly that you want to reference (one or more than one):

dotnet 
{ 
  assembly(YOURASSEMBLY) 
  { 

  } 
}

and finally you have to add a reference to a .NET type from the referenced assembly (by using the .NET fully-qualified name and giving it an alias that you will use for referencing the .NET type from AL code):

dotnet 
{ 
  assembly(YOURASSEMBLY) 
  { 
    type(YOURDOTNETTYPE; ALIAS) {} 
  } 
}

So, how can we transform our previously developed C/AL code for external document printing to be used in AL for the next on-premise Dynamics 365 Business Central version?

The first thing to do is starting a new AL project with Visual Studio Code, open the app.json file and insert the following line:

DotNetAL_01.jpg

This means that your extension is targeted for the on-premise deployment.

Then (extremely important!), you need to instruct the compiler where it has to search for assemblies. By default, the compiler only knows the location of the mscorlib assembly. To add new assembly paths for the compiler, you need to open Visual Studio Code user settings and add the following lines:

DotNetAL_02.jpg

The “al.assemblyProbingPaths” setting instructs the compiler where to search. Restart Visual Studio Code after adding this setting.

After that, you can start coding. Exactly like in the C/AL sample, I have a codeunit that does all the tricks. In my AL project, I’ve created a codeunit called DotNetWrapper that:

  1. Declares the DotNet assemblies that I need to use
  2. Declares the functions that uses the DotNet variables and performs the actions

The AL codeunit is as follows. First, we declare our .NET assemblies:

DotNetAL_03.jpg

and then in our functions we can use the .NET types by declaring DotNet variables:

DotNetAL_04.jpg

Having DotNet variable support for the on-premise is a must and now we have a great way to handle these scenarios. What about the SaaS? Nothing change for the moment 🙂

P.S. a small note about a noisy effect I’ve observed in Visual Studio Code when declaring the dotnet package: VS Code could give you an error indicating that the .NET assembly cannot be located. First, restart VS Code. If the error persists, just force a compilation and it will magically disappear.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s