Last couple of days, I got a number of questions from people that all came down to the same issue: how to set the correct settings in the launch.json so Visual Studio Code can connect to NAV 2018. In most cases I saw the same mistake being made. A logical mistake, but also one that leaves you probably wondering why it works that way.
Let’s assume you have enabled the development port in your NAV 2018. Look here to read how that is done.
When you create a new workspace in VS Code with the AL:Go! command, you get by default a launch.json that looks like this:
Basically the only thing you need to change is the servername. In my case that would be navserver. Some people also change the default developer port 7049 to another port number, let’s say 7149. A common mistake is to put that port number into the server url.
Let’s see what happens when we try to download the symbol files.
It uses port number 7049! How is that possible?
The port number in the server url is just ignored. Instead you should specify the port number with a separate setting. If that setting is missing, then the default port number 7049 is used. Let’s specify the port number and see what happens.
Let’s download the symbol files again, and watch the url.
Conclusion: do not specify a port number in the server url. Instead, use the port setting to specify the developer port number.
Another common mistake is that the server url and the web client url are assumed to be the same. That is not the case. The two settings we talked about above, the server url and the developer port number, are the only settings you need in the launch.json.
When VS Code publishes the extension to the NAV server, the NAV server returns the web client url as a response. This url is then opened in the browser. No setting needed in the launch.json at all.
The NAV server reads that setting from the Web Client Base Url server setting.
Let’s prove that with an example. In the next screenshot, I set the key to a different value. Sorry, it’s PowerShell, I only have NAV 2018 installed with docker images. 😉
How to check the output? Well, I can of course show a browser screen with that url, but would that prove my point? So I figured that a Fiddler trace would probably more convincing. Here is the Fiddler trace when VS Code publishes the extensions to the server.
Look at the response, it contains the setting that I did with the PowerShell command.
And here is what happens when the Web Client Base Url is not set:
I hope this demystifies how VS Code and the NAV server work together!
Pingback: How to connect Visual Studio Code with NAV 2018 - Kauffmann @ Dynamics NAV - Dynamics NAV Users - DUG
Pingback: How to connect Visual Studio Code with NAV 2018 | PA
Hi Arend-Jan,
Mine did not work with NAV 2018 unless i enter the servername in both the name and the server parameter in tje launch.json file.
I got a strange error message: the … .app file is not found.
Setting the parameters like this fixed it:
“name”:“navserver”
“server”:“http://navserver”
Thanks for sharing, Peik. I haven’t seen that behavior, and to me it looks strange that the name has anything to do with that. As far as I know the name is used to display on the status bar and to enable multiple configurations in the launch.json. Anyway, if one runs into such a problem, it’s worth to give it a try.
Hi Peik,
I am currently facing the same issue here with a NAV 2018 instance on a local server.
Although basically I agree with Arend-Jan, I tried what you recommended and on the launch.json file, I adjusted the Name parameter to the same value as the Server parameter, but without success.
Have you got any further insight into the problem by now to maybe get to the source of the issue ?
Cheers
Andrew
You get the same error message ‘the app file is not found’?
When you can’t access the server that is specified in the launch.json it is in most cases one of these reasons:
– the ip address of the server can’t be resolved (check with ping)
– the firewall on the server blocks port 7049
– the nav server is not running
– the NAV credentials are not correct
– the NAV credentials are correct, but the user does not have permissions
AJ
Yes, the same message.
I can download Symbols from the NAV Server Instance so I assume communication to the NAV Server is properly established.
Anyhow, I double checked everything but couldn’t find any issues.
Authentication is Windows, the user in charge has SUPER permissions.
I did also try to run VSCode on the NAV APP Server itself – same issue.
Andrew
Hey AJ,
finally I’ve got it!
Instead of simply using F5 to build and deploy, I started using the AL commands provided by the AL Language Extension from the Command Palette directly:
Step 1: AL:Package –> builds the .app package file in the root of the project folder
Setp 2: AL:Publish –> deploys the extension to the specified NAV server instance
I am still wondering why it does not work for me with F5 only as described in the tutorials but at least I’ve found a solution that works for me.
Thank’s again for your support in this issue and my appologize I’ve abused your platform for troubleshooting. But I am happy to be able to share a solution at least and hope this may help other guys as well.
Cheers
Andrew
I don’t have an answer why F5 does not work. No problem to use my site, but I think you get a better chance to solve your issues with AL and VS Code by posting them on the GitHub repository: https://github.com/Microsoft/AL/issues/
AJ
Which credentials I should use to allow connection between VSCode and NAV?
I thought that Docker has created a “copy” of my physical Windows account when creating a container with NAV. I can login using those credential to the NAV2018 web client.
But when I try to publish files from VSCode to NAV those credentials are rejected. When I use authentication:UserPassword option, VSCode prompt me for login/password, but it’s rejected. When I use option authentication:Windows I got error 401 “No authorisation. No credentials are available in the security package”.
Any advice?
I’m afraid I can’t help you with Docker containers and Windows accounts. I always use NavUserPassword, which always works for me.
I see. But can you confirm me which account VSC uses to login to NAV development service? Is this normal (?) NAV account?
Should my instance have some option enabled to allow VSC login?