AL Extensions: Custom Build Process Using Visual Studio Code Tasks

I recently discovered the Tasks menu in Visual Studio Code and after a bit of wondering why I’ve not seen it after using VS Code for many months, I then took a quick look into what it was all about.

Turns out VS Code has yet another amazing feature called Tasks, which let’s you automate things such as builds, packaging, deployment, and probably whatever else you can think of. You can read all about tasks in detail here.

This got me thinking, I wonder if I can use this to make my own build process for AL extensions? Turns out this is quite easy…and here’s how you can do it.

Open up your AL extension folder and select Tasks > Configure Tasks.

TasksConfigureTasks

In the command palette select Create tasks.json from template.

CommandBoxConfigureTasks

In the command palette select Others.

CommandBoxSelectOthers

You’ll now see a tasks.json file create in the .vscode folder of your AL project.

tasksJsonFile

In the tasks.json file you’ll see some default settings like this:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "echo",
            "type": "shell",
            "command": "echo Hello"
        }
    ]
}

We need to change the task command so that we build our AL extension. When you install the AL Language extension, behind the scenes is installed a command line compiler (alc.exe). The alc compiler accepts 3 parameters:

  1. project: The path to the AL project folder
  2. packagecachepath: The path to the folder containing the reference packages
  3. out: The path to output the packaged extension app file to. This parameter is optional. If it’s not specified then the compiler will output the app file in the project folder with the default name of <Publisher>_<Name>_<Version>.app

For example, in order to build our AL extension with the default output and name, we’d need a command such as this:

C:\Users\<username>\.vscode\extensions\Microsoft.al-0.10.13928\bin\alc.exe /project:C:\ALProject1 /packagecachepath:C:\ALProject1\.alpackages

One more quick thing before we continue. Within VS Code tasks, you have access to some predefined variables. You can read about what they are here. For our task, we’re interested in the ${workspaceFolder} variable, which will give us the path to the workspace folder of the project.

Back to the VS Code task. We need to update the tasks.json file now. We’ll change the taskName property to a more meaningful name, and we’ll update the command property to execute our alc compiler. Make sure to note the double slashes and that you replace the <username> and AL Language extension version number with the correct one as per your environment.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Offline Build",
            "type": "shell",
            "command": "C:\\Users\\<username>\\.vscode\\extensions\\Microsoft.al-0.10.13928\\bin\\alc.exe /project:${workspaceFolder} /packagecachepath:${workspaceFolder}\\.alpackages"
        }
    ]
}

Now that we’ve updated the task file, you need to set this task as the default build command. To do that you select Tasks > Configure Default Build Task from the menu. Doing this will not change the existing F5 or Ctrl+F5 commands that Microsoft delivers with the AL Language extension.

TasksConfigureDefaultBuildTask.png

In the command palette select the name of the task you created above. In my case, I’ve named the task Offline Build.

CommandBoxSelectTaskName

The following lines were just added to your tasks.json file:

"group": {
    "kind": "build",
    "isDefault": true
}

You can close and save the tasks.json file now if you still have it open. You’re ready to use your new build task in the following ways:

  1. Tasks > Run Task
    • With this method you can select to run any task that you’ve created.
  2. Tasks > Run Build Task
    • This will work only if you’ve made your task the default build task.
  3. Ctrl+Shift+B
    • This will work only if you’ve made your task the default build task.

No matter what method you choose to execute the task, you can monitor it for errors in the VS Code terminal window.

TerminalWindowOutput

That’s it! Now you’ve got a way to build your extension without having to deploy it at the same time.

Pretty sure I’ve only scratched the surface on what VS Code tasks can do, so I’m excited to see how else I can make use of them in my AL development.

Until next time…..happy coding!

 

 

Advertisements

Learn AL: New string features

The AL language is bringing some nice features to Dynamics NAV developers. I want to cover a couple of the cool new string features.

  1. Function chaining
  2. Replace() function

The following example is something I’ve used in the past numerous times. It finds and replaces a substring within a string. Created in Visual Studio Code, but using good ol’ C/AL syntax, the code would look something like this:

NewString := DELSTR(OriginalString,STRPOS(OriginalString,FindString))
                + ReplaceWithString + COPYSTR(OriginalString,STRPOS(OriginalString,FindString) + STRLEN(FindString));

The above function is easy enough to create, but it was always something that I thought should have been part of the system functions. In AL, we now have the Replace() function, which can be used like this:

NewString := OriginalString.Replace(FindString,ReplaceWithString);
Oh by the way……invoking string functions directly from the variable!? Yes!
Using the “<variable>.<function>” syntax, we can now chain multiple functions together like this:
NewString := OriginalString.Replace(FindString,ReplaceWithString).ToLower();

Whoah! Pretty cool right!?

If you’re not always familiar with function chaining, I should point out that the functions in the chain get applied to the string from left to right, Depending on what you are doing to the string, the order you define the functions in the statement will matter.

This is some fantastic stuff and really brings Dynamics NAV development inline with current development practices.

Until next time, happy coding!

Create a Dynamics 365 Sandbox Environment

Microsoft has given us the ability to create a sandbox environment based on the Dynamics 365 platform. This will allow you to try out new setups, extensions, and even develop new extensions in a safe isolated environment. This is perfect for testing new extensions in a true Dynamics 365 environment.

Each Dynamics 365 subscription is allowed to create one sandbox environment for no additional charge. You can even tear down and reset your sandbox as necessary.

To create a sandbox environment:

  1. Sign in to your production instance of the Financials service.
  2. Choose the Search for Page or Report icon, enter Sandbox Environment, and then choose the related link
  3. Select Create.
    Another tab in your browser will open for finishing the setup of your sandbox environment.
  4. When the sandbox environment is ready, you will be redirected to sandbox environment’s Welcome wizard.
  5. Choose Learn more to read about scenarios that you can try in a sandbox environment. Or, choose Close to continue to the Role Center of your Financials sandbox instance.
  6. At the top of the Role Center, a notification appears to inform you that this is a sandbox environment. You can also see the type of the environment in the title bar of the client.

Once the sandbox has been created, you can access each environment directly with the following URLs:

For more information, see the original Microsoft article here.

Happy coding!

Dynamics NAV 2018 on the way!

After delivering a message at Directions NA 2017 that the typical October release if Dynamics NAV would be delayed until spring if 2018, an article posted by Alysa Taylor (GM of Global Marketing) confirms now that there will be a release of Dynamics NAV 2018 by the end of the current center year.

Check out the full article here.

This is a great response by Microsoft to address what was largely a negative reaction to the Directions announcement, and confirms that they are listening to our feedback!

Dynamics 365 ‘Tenerife’ Release Plan

Quick update on the release plan for the next iteration of Dynamics 365 ‘Tenerife’ (fka Dynamics NAV).

The next release for on-premise deployments was announced to be in the spring of 2018. This is a change from the typical October releases that we’ve been used to for the past 7 years or so.

We’re not sure what the final product name will be at this point.

This change in the release date came as quite a shock to the audience at Directions NA 2017. So much of a shock that Microsoft announced during the closing keynote that they will look into the current release plan to see if there’s anything they can do to get it out ahead of plan.

That’s all for now, happy coding!

Thoughts on Directions NA 2017

I’m back home after spending some time at Directions NA 2017. It was…..crazy and amazing! It’s always a fun and informative conference, and this year definitely did not disappoint.

I’m not going to focus on ‘the crazy’, as I’m sure you’ve probably seen countless other posts about it already. 🙂

Dynamics 365 ‘Tenerife’. Is it the final name? No. Is the NAV name being dropped? Sounds like it.

Dynamics 365 Tenerife: it’s cloud; it’s on-premise; it’s really freakin’ cool!

One more thing. No matter if you are a coder, an implementer, a sales person, or a little bit of everything, things are changing, and they’re changing FAST. Scary? Of course…..change always is, but I have 100% confidence that Microsoft’s direction is the right direction to go. We have been living in an online world for a number of years. No longer is the message “the cloud is coming”. The message is now “the cloud is here”. Hopefully you’ve been moving to the cloud already. If not, you are behind the times; it’s time to get your products to the cloud ASAP!

For developers, you have to put back on your learning hat and if you’ve not already started, begin looking at extension development using the new development tools, namely Visual Studio Code. It’s a new tool, but not “really” a new language. C/AL is a great language, so why would Microsoft do away with it? Consider the new AL language as ‘C/AL 2.0’ if you want. Same syntax, plus a load of new features that makes development even faster than it was in C/Side. With built in object types to connect to web services or process xml data, to new string builder commands, the development platform has been improved to an absolutely amazing level…….and that’s not even considering all of the goodies that Visual Studio Code brings us. Customize your development tool to however you like using a massive library of different extensions. Visual Studio Code has quickly become my go-to tool for much more than AL coding.

There’s so many cool things that need to be talked about in detail. The Microsoft Graph API that is being developed for the Dynamics 365 platform is something I want to spend some time with in the near future. Finally having a documented common set of APIs is something that I think is going to make our lives as developers extremely better…….and yes, the APIs work on premise too. 🙂

So many things to learn outside of what we’d typically refer to as the “NAV system”. Case in point, I spoke at a session regarding test drives on AppSource, which up until 2 weeks ago, was a completely foreign topic that I knew nothing about, and never thought I’d need to know anything about. Turns out though, with minimal development work, it’s incredibly easy to hook up your Dynamics 365 published app so that any Office 365 user (admin or not) can spin up a session to try it out, free of charge to them.

I know I’m probably forgetting a load of other cool things that were covered at Directions NA 2017, but trust me when I say that Microsoft is stepping on the pedal hard and going full steam ahead. Dynamics 365 Tenerife is a testament to that for sure.

It’s all so very exciting!

Until next time, happy coding!

 

 

64-Bit Visual Studio Code Available

Beginning with the July 2017 update, Microsoft is now pushing out a 64-bit version of Visual Studio Code. If you have an existing 32-bit version installed, you will not automatically be updated to the 64-bit version.

All you need to do though is manually uninstall your 32-bit version and install the 64-bit one. All of your existing extensions will be picked up by the new version and should continue to work.

Grab the 64-bit version here.

Happy coding!