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:
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.
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.
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 firstname.lastname@example.org and I wish you productive business.
Thanks to you, Stuart, no redesign was necessary for iFacto Revision :-).
Thank you for this update, you touch some interesting subjects regarding the NAV team focus points in 2013.
(And great job btw, 2013 is a great product release, but as a developer, I must say that it's a giant leap in the right direction on so many many areas).
You ask for thoughts and suggestions, I would like to drill you on the future platform of the IDE.
You talk about how the RTC client could work as an IDE.
Personally I've been wondering more about "when", rather than "if", the future IDE of NAV will be based on Visual Studio.
I believe many think of Microsoft as an industry leader in regard of development tools, because of Visual Studio.
Many of the obivious short commings of the current Development Environment, are available in Visual Studio and with the DotNet interoperability i NAV, (now being used more than ever with the death of the Classic client), Visual Studio seems more and more like a good fit, IMHO.
What are your opinions/impressions on the future platform of the NAV IDE?
I agree with JS Agidon.dk Microsoft has THE IDE - Visual Studio. I think most developers would prefer doing development in Visual Studio. By the way, we already do design reports in Visual Studio.
But my #1 request would be to have integrated source control. I tried iFacto Revision, but it seems to track changes per-object which is not always useful since many changes often require modifying two or more objects.