At Directions in the US this year, Microsoft announced that they would release a preview of the new development tools for Dynamics NAV. Today, they have delivered on that promise, and you can try them out in your Azure subscription. Head on over to the Development Tools Preview for Dynamics NAV to read all about it. You will find instructions on how to get started there. Go to the New NAV Development Environment on MSDN to read more about the details.
If you decide to take the tools for a test run, and you find any issues with them, you can report on those issues in the AL Github issue tracker. Go to The Microsoft/AL Github page, click on the ‘Issues’ tab and create a new issue there. Microsoft is monitoring the issues there.
The important part to keep in mind about this preview is that it gives us a preview of how development for extensions is evolving. The goal is to simplify the process to where all we need to do is write the code and hit a build button, and all internals are taken care of by the environment.
Remember, this is just a preview of the tools. It is not supposed to be flawless. Microsoft is also working on many other tools to complement VSCode and provide a development experience that will meet the NAV developer’s needs.
Today marks something quite unique, at least for the NAV world. Microsoft is actually giving us a preview of a preview product that they have announced for Christmas.
During this year’s conference season, Microsoft has shown their vision of the future development tools for Dynamics NAV. We’ve seen various demonstrations of how we will be doing development for NAV in Visual Studio Code, a lightweight development tool. Today they have put some sample files on GitHub (Check it out here) for all of us to look at and to critique.
Visual Studio Code (VSCode for short) is available on Windows, but also on MacOS. Since my main computer is a MacBook, I wanted to see if it really does work. To be modifying NAV objects within VSCode on a MacBook is an almost surreal experience, but here’s proof:
The sample is a simple “Hello World” application, with a couple of codeunits and a so-called ‘page extension’ object. Part of the vision for future development is to make building extensions easier. Without going into any detail of why that is important, this will make extension and app development a LOT easier to do.
Some of my thoughts:
Microsoft is finally taking NAV development into a professional development tool. Hopefully this will inspire (or at least not deter) a new generation of NAV developers
json files for configuration and for the app signature will make automating deployment much easier
No more control ID’s, which means those will no longer cause upgrade headaches
I would like to also get rid of object ID’s, which they have said that they are looking into. Current licensing is based on object ID’s though, so I’m not holding my breath
It will be interesting to see if there is any automatic sorting by control type. For instance will you be able to mix fields and functions in a table object, or will the compiler automatically sort this for you. There’s potential to really mess up the object’s readability
This is Visual Studio Code, not Visual Studio. It is still to be seen whether C/AL will be a fully functioning .NET language, and it is still unknown whether we’ll have access to other .NET goodies from this editor
Lastly – we are getting just a preview of the tool. Nothing was said with certainty about when this is ready for prime time. What is REALLY cool though is that Microsoft is inviting everyone to participate in the process
Go check out the files for yourself, and if you’d like you can even contribute to the GitHub project. For me, this is a very exciting prospect, and I can’t wait to see what happens next.
Earlier this month I wanted to write about what’s new in NAV 2017, and my fellow MVP and good friend Eric ‘Waldo’ Wauters beat me to it. So, my next plan was to write something comprehensive about extensions. I am signed up for a deep dive workshop next month, and I want to be well prepared. Again, as I am collecting information, this guy publishes a large post about extensions, and judging from the title it looks like it was the first of three posts. So…. instead of doing the work myself, I waited for him to post number three, and give you the links in here: Part 1, Part 2, and Part 3.
I could try and say something intelligent about these posts, but I’d make myself look foolish. After the workshop I’ll have plenty to share anyway. Enjoy 🙂
Just a quick post today about something that is probably the most important thing to learn as a NAV developer, which is Extensions.
I remember going to an event where Steve Ballmer did the keynote. It was a technical conference, and he started his talk by almost screaming “DEVELOPERS! DEVELOPERS! DEVELOPERS!”. It was meant to make the people in the audience, who were almost all developers, like the most important people on the face of the earth. He kept hammering on the point that developers were THE MOST IMPORTANT to Microsoft, and showed us all kinds of evidence that this was the case.
This past year or so has seen a big push toward this new thing in NAV development called ‘Extensions’. Rather than modifying the base code of the product, which is what most of the NAV partner channel is doing for their customers, extensions allows you to create custom functionality without actually touching the base code itself. Coming back from Directions this year, it has become clear that Microsoft is ALL IN on moving NAV development toward extensions. My fellow MVP and good friend Eric ‘Waldo’ Wauters wrote about extensions as well this week, so I won’t bother repeating that part.
What I want you to know about extensions is that as a technical NAV professional it is essential for you to learn about extensions. Your ability to keep your relevance in this industry will depend on whether you are able to effectively use extensions to develop a custom solution for NAV. Apps for Dynamics 365 are only possible with extensions, but it might even become necessary to use extensions for on prem implementations.
I’m signed up for a full day pre-conference workshop at NAV Techdays this year, which will hopefully give me the necessary skills to get that started for me. What are you planning?
After reading this blog and watching this YouTube video, you should have enough information to start figuring out how to use XMLPorts to import flat text files, even when this file contains data for multiple tables.
When I first got started as a NAV developer, I was assigned a senior whose job it was to educate me about what it takes to be an effective NAV developer. Whenever I had a question he would always challenge me to figure it out myself, while maybe giving me a tiny little push in the right direction. At first I thought that was very annoying, but it forced me to develop what is probably the most important skill as a developer: the skill of “figuring out how stuff works”. Once he was satisfied that I had spent an adequate amount of time and brainpower to a problem, he would take the time to give me a lesson. Sometimes he would make these lessons up on the spot, because he had to figure it out himself. Those lessons are my favorite memories of my time learning how to be a NAV developer, and oddly enough most of them weren’t even about syntax or objects, but about “how to figure stuff out”.
Every day, I make my rounds through the online communities, in search of questions to answer. Sometimes, I find a question that makes me wonder myself how something works. When this happens, I take a standard NAV database, and spend some time in the evening hours to figure it out. The past few days there’s been a question about how to import data for multiple tables into the RTC from a flat file, using an XMLPort. Now, at my work, all the developers attend a weekly conference call. On these weekly calls one of us presents a technology, or some tips on how to do certain things. We had recently held one about XMLPorts for the RTC, so I felt confident that this one would not be too big of a problem for me.
While my wife took my daughter to dance class, I worked on a couple of XMLPorts for the RTC, to import Purchase Invoice information into NAV. The YouTube clip below describes the results of those efforts. Hopefully this will help you understand how this works.
With NAV 2013, Microsoft has added the capability to expose data from your NAV system as OData Web Services. Where that differs from regular Web Services (which in the NAV Server management snap-in is now identified as ‘SOAP Services’), is that OData only exposes data feeds, and within the context of Dynamics NAV is read-only. Click here to read all about OData, and here for an overview of OData in NAV 2013.
I’ve put together a new YouTube clip to show you where to find the OData Web Services in the NAV Server Management tool and the Web Wervices table from the RTC, as well as a couple of examples of how to consume them. As you will find out fairly quickly in this video, I have a LOT to learn about OData. I wanted to share what I do know though, and give you an idea of where to start looking.
This provides a new way to expose data from NAV, in an industry standard way, although I am sure that true OData experts will find missing pieces. It is another possibility for us to expand the reach of the ERP application that we know and love. I hope you enjoy the video, and that you will be inspired to start learning about it, and maybe even get some ideas about how to use them for your business.
In NAV 2013, Microsoft has introduced some very nice new features to make designing Page objects for the RTC much easier than we were used to in NAV 2009.
Remember the good old days, when we had a wysiwyg designer for the Form objects, and we could put anything we want, anywhere on the form? This made for some really ‘creative’ (ahem) solutions, but essentially we were used to having complete control over the look and feel of the forms. When the RTC was introduced, we got the first step into a completely independent display target. Instead of defining x and y positions, display elements are now defined by metadata, and the display target should then be smart enough to interpret the metadata when the object is rendered. The intention was to ultimately have a situation in which it doesn’t matter where the page is displayed. The page object itself can be identical, and the display target then decides how to display certain elements based on the capabilities of the display target. For instance, the RTC displays exactly the same page as the Web Client or the Sharepoint Client, they just display the same page differently.
Unfortunately, when all you see is metadata, developing Pages becomes a very abstract exercise. Since there is no direct connection between the development tool and the rendered object, what we had to do was save the object, and hope for the best from there. We had to actually run the page to see what it would look like, and finding individual elements was a very painful thing to do. Lucky for us, the NAV team in Denmark cares a great deal (a GREAT deal) about what we think of the product, and they are VERY proud of the tools. When they were receiving many complaints about the Page Designer, they decided to enhance the development experience in NAV 2013 and address some of the most-frequently-complained-about issues. In my opinion the result is a HUGE improvement over NAV 2009.
What I want to do is focus on two new capabilities in the Page Designer. The first one is the ability to preview the Page right from the Page Designer, without saving the object first. My favorite feature of this capability is that there is a link between the ‘metadata designer’ and the ‘page previewer’. When you click on an element in the ‘metadata designer’, it is highlighted in the preview, and vice versa. You can see a rendered version of the metadata before saving it, and have a visual clue of what you are doing. The second (there is an ‘A’ and a ‘B’ here) is the ability to add columns to the Page object, through a Grid Layout and/or a Fixed Layout. These two new types of group elements make it possible to display multiple columns on the Page.
The NAV 2013 online help has a lot of good information about Page design, with walkthroughs and other tutorials. I’ve created a YouTube video in which I take you through the various screen elements of the NAV 2013 RTC, and then into the Page Designer to show you these new capabilities. I hope you’ll enjoy the video, and hopefully you’ll feel a bit more confident in using the Page Designer.
We’ve never had a debugger quite this powerful and versatile. Debugging NAV 2013 is Easy!
By nature I am a pessimist. In any situation I tend to look for problems and point them out to everyone. Since my goal of pointing out the problems is always to SOLVE them, and leave the situation in a better state than I found it, I personally consider my natural pessimism a very positive attribute. One of the things that feeds this pessimism is previous, similar situations. One example of such a situation is the release of a new version of NAV. When this happens, the NAV developers are always hoping that the tools have improved, and for well over a decade, one especially sore point has been the debugger.
When I first started as a Navision developer, version 2.5 had just come out, and most of the customers I worked on were still on earlier versions. The debugger in those days was TERRIBLE. Even then, coming out of a job as a VBA developer, I knew that there were much better alternatives, and I was always surprised just how bad the debugging experience in Navision was. Granted, there have been significant improvements since the 2.5 days, but the worst day in NAV development history surely must have been when NAV 2009 came out, and the only way to “debug” the RTC was the workaround with the Visual Studio debugger (see this video on how to make that work). Given all of these previous experiences, let’s just say that I was realistically pessimistic for the NAV 2013 debugger, and my expectation was actually a continuation of this downward trend ;).
As I’ve said many times before, the NAV team actually cares a great deal about the development experience, and for years they had been wanting to address the development tools. They were well aware of the problems, but the priority to do anything about it was always too low to make it into a new release. With the discontinuation of all the Classic components, however, this changed and there finally was ample priority for a new debugger. The results of years of very hard work are very impressive, and in my opinion the NAV team has delivered something that is well beyond anyone’s reasonable expectations. The new debugger is a great tool, one that gives the NAV developer a lot of flexibility. Not only can we break into any type of session on any Service Tier (given the proper setup), we can even change the appearance of the debugger, and customize it to our own personal preferences.
This is another one of those things that I’ve been very anxious to share, and I am very happy that I finally had some time to put together a YouTube video and write this blog entry. Please enjoy the debugger, and I hope you are as happy with it as I am.
Not too long ago, one of my customers had an issue with the RTC that we needed to debug. Instead of using the Visual Studio debugger, this customer was used to reproducing the problem in the Classic client, and debug the process there. The perception was that running the Visual Studio debugger was very difficult, and they would not be able to read the C# code. I showed them how easy it is to enable the debugger, and how the C/AL code is always part of the C# code in the form of comments. As I was talking to folks at NAVUG Forum and Convergence, I was very surprised to hear that even seasoned NAV professionals are still not using the Visual Studio tools.
The information about how to use the debugger is available here in MSDN online, and it has been discussed many times in the online forums. Since I’m a visual learner, I decided to make a YouTube clip that shows you how to enable the Service Tier for debugging, and how to attach the Visual Studio debugger to the server process.
