Right now the keynote for //Build 2015 is running. And something has changed, Dynamics has already being mentioned TWICE !!
At Build 2012 in Seattle Dynamics wasn’t even on a slide with ERP system shown at the keynote.
One more, Dynamics AX mentioned during the Office Graph talk.
Dynamics apps in the new Windows Store For Business
I will keep updating this post with Build+Dynamics impressions.
Today I upgraded a virtual machine running NAV2015 from Update 5 to Update 6. Not a big deal, but during the process I managed to delete the CustomSettings.config file – Stupid mistake on my part.
This file holds the entire configuration for the NAV Service Tier, from authentication of client to SQL Server connection and more.
But the real question I’m left with is:
Why does NAV keep its setting files under C:\Program Files ?
With the introduction of Longhorn (Windows Vista/Windows Server 2008) and UAC – Writing inside c:\Program Files became a elevated operation, so only users with Administrator rights could write there. After that, most programs began to use c:\ProgramData or storing setup and data under c:\Users. There is even a blog from Microsoft on the subject.
Funny enough, SQL Server still defaults its location for DATA under c:\Program files unless changed during the install. They properly keept it there for historic reasons – It has been that way since SQL Server 6.5.
But NAV does not have that history restriction, so from my perspective, this can be added to Luc’s Lets clean up NAV list.
Anyway, that was my friday rant 🙂
In this series of articles I will explain a alternative method of handling user documentation for Microsoft Dynamics NAV 2015 code.
In E Foqus we use this for our ISV product Foqus Finance, but it can be used for any NAV solution, ranging from a small customer modification to huge ISV solutions (as Foqus Finance)
We have tried to solved a series of challenges with documentation:
First challenge: Documentation is dead the minute you’re finish writing it. Code changes, customers want it work differently, change requests keeps popping up. And the documentation (if any) stays at the initial level
Second challenge: Documentation is kept in documents (Word/PDF) sitting on local drives, attached to email, stored on file shares, often in multiple versions without any clear version strategy.
Third challenge: Customer want F1 help, and this has historical been an nightmare to create with NAV – from compiling CHM files with 3rd party tools to distribute files to clients.
Fourth challenge: New formats comes along all the time, creating an ebook with the help would be a very modern thing to do.
Read on for our solution to all this:
Step 1 – Organizing the input text
Step 2 – Getting structure into our documentation
Step 3 – Graphical Layout
Step 4 – Updating the Help Server Table Of Content (ToC.XML)
Step 5 – Editing and storing help text with NAV Code
Step 6 – Running the whole thing
Download the current version of the help toolkit:
Step 7 – Producing automated screenshots from NAV