In Microsoft Dynamics NAV 2013, the Microsoft Dynamics NAV Classic Client has been renamed to the Microsoft Dynamics NAV Development Environment. We did this not only because we like long product names but because we want to call attention to the fact that the development environment is now specifically repurposed to developers only. C/SIDE (Client Server Integrated Development Environment) is no longer an end-user client and we’ve made several changes to the client to support its role. C/SIDE has always been the development environment and it’s been the jumping off point for third-party developer tools, both commercial and community sourced, and we know that the success of Microsoft Dynamics NAV 2013 is going to hinge on those tools continuing to work for you.

But if C/SIDE no longer supports running C/AL code, then how can we make that claim?

Before jumping in, I’d like to share a couple of thoughts about where we’re going with the development environment and a few thoughts about the different types of solutions that we’ve seen.

First, the Application and Client have moved to the Windows Forms Client/NAV Server with the Microsoft Dynamics NAV 2009 release and we’ve had several releases since then. In the meantime, C/SIDE has both stayed as the (almost) single development environment and slowly evolved to its position in Microsoft Dynamics NAV 2013 where it’s no longer an end-user solution. We’ve talked a lot about moving the developer tools to the RoleTailored client, mainly because we think it’s a good fit to have the developer tools as part of the client (or part of the solution environment, however you want to think of it) and we think it’s a good fit because the UX offered by the RoleTailored client is a good match for a development environment. Task pages allow you to work atomically, FactBoxes allow us to share related information, Actions are good for functions, and so on and so forth.

In Microsoft Dynamics NAV 2013, we made an explicit decision to not build the developer tools in the RoleTailored client and to instead focus on the following areas:

• Improved debugger. This was a #1 priority as without Forms and the Form Transformation Tool based development process, there was no realistic way to debug a solution.
• Improved page development. This was also a very high priority. The lack of WYSIWIG support for UI development was often cited as a reason for low uptake of the RoleTailored client.
• Improved upgrade. We knew there would be lots of changes in Microsoft Dynamics NAV 2013, including breaking old file formats, and we needed to make sure we assisted people rather than putting up more roadblocks.

In Microsoft Dynamics NAV “8” and beyond, we see new areas that we didn’t think of when we were starting Microsoft Dynamics NAV 2013 and we’re likely to give them equal consideration along with the developer environment. We look at the requirements brought by Azure and the desire to scale. We ask the question -- how does the deployment of a FOB file work when you have 1000 running instances? We also see the value in personalized clients and know that the user personalization settings are orthogonal to the Page in FOB/Text format – how are we going to solve that problem? We are also constantly challenged by questions about source control and other Microsoft product integrations (like Visual Studio based solutions & TFS) and we will factor those thoughts into our planning alongside the main goal of moving all development into the Microsoft Dynamics NAV Server stack.

But back to the Microsoft Dynamics NAV Development Environment and using the developer environment with third-party tools or extensions. To review a couple of basics, the following have been implemented in Microsoft Dynamics NAV 2013.

• Native Database Format has been removed. Microsoft Dynamics NAV 2013 is SQL only. Furthermore, the FBK format is still supported but only Microsoft Dynamics NAV 2013FBK files can be restored in Microsoft Dynamics NAV 2013.
• Forms are not supported and have been removed as application objects and removed in the platform. (You can’t just import your old ones – they won’t work.)
• Dataports are not supported – use XMLPorts.
• C/AL code no longer runs in C/SIDE. Using the Run button in Object Designer will cause that object to run on the Microsoft Dynamics NAV Server instead.

After reviewing these points, we saw that in Microsoft Dynamics NAV 2013 we needed to port any third -party tools to be Page object based. If the tool uses C/AL, then pages and code have to be validated on the Microsoft Dynamics NAV Server.

We’ve seen several categories of ‘external tools’ and I’ll share those and their migration story here.

• Pure Vanilla Utility. Pure Form/C/AL utilities exist and can be ported safely to being Page/C/AL based. Examples are small tools for updating data in the database or for generating statistics on data in the database. We recommend that in your Microsoft Dynamics NAV R2 version you run the R2 Form Transformation Tool to generate the pages and then upgrade those to Microsoft Dynamics NAV 2013.
• Integrated Tool using C/AL Compilation as a sub-step. These tools are similar to Pure Vanilla Utilities and can be ported to being based on pages. The notable exception is when the tool should validate an object using compilation, then a change must be made to use the Microsoft Dynamics NAV Development Environment command line interface. The development environment now offers Import/Export and Compile object as command line functions, which can be used to trigger compilation and get error information via a log file.
• External Tools relying on alternative interfaces/data sources. Some tools have been built on platform features like Client Monitor that have not been ported to the Microsoft Dynamics NAV Server. Other tools have relied on unsupported
  interfaces like nsobjectxproxy.dll to fish for event information from the object designer. Microsoft Dynamics NAV 2013 ships with nsobjectxproxy.dll and an alternative implementation of Client Monitor where the information is stored in the SQL Trace Logs. These tools are likely to require significant redesign work to run in Microsoft Dynamics NAV 2013.

For many people, the command line options offer an interesting new entry point for the Microsoft Dynamics NAV Development Environment. Examples are shown here:

finsql.exe command=compileobjects, servername=<server>, database=<database>, [filter=<filter>], [logfile=<path and filename>], [username=<user name>], [password=<password>], [ntauthentication=<yes|no|0|1>]

finsql.exe command=importobjects, file=<importfile>, servername=<server>, database=<database>, [logfile=<path and filename>], [importaction=<default|overwrite|skip|0|1|2>], [username=<username>], [password=<password>], [ntauthentication=<yes|no|1|0>]

Thanks for reading and thank you for your continued interest in Microsoft Dynamics NAV 2013 and developer tools. With your feedback, we can make future versions of Microsoft Dynamics NAV even better. I’m always interested to hear your thoughts and suggestions. My email is sglasson@microsoft.com and I wish you productive business.

-Stuart Glasson