As you know my daily work is highly depending on Visual Studio Team Foundation Services, so when last week VS 2017 was released, I immediately installed it and continued my work as before. It's one of those great things of VS: a high up- and downward compatibility. It makes me smile.
Nevertheless there are always a couple of things that I need to reinstall to have my setup the way I want it. Among them:
For this I lately used Steve Fenton's post Add Visual Studio Command Prompt To Visual Studio 2015. Straight forward to implement. However for 2017 it needs some tweaking with respect to the argument:
The VS Command Prompt will now be available in: Tools > VS Command Prompt
Last weekend I spent time to get things working on my Azure machine for the fourth week of the Junior Developer Training. A five week course I am running since last fall for Dynamics 365 Training Ltd. in the UK. While compiling the code of our example application I ran in to the following error:
"Ouch," I thought, "not again."
I had ran into this issue on my laptop a couple of months ago. At that time I was working on some label printing issue with Torben Wind Meyhoff and Niels-Henrik Sejthen, of the NAV team in Lyngby (thanx again guys for stepping in). To solve the label printing issue Torben had proposed to use a WORD layout. But ever since we had upgraded from 2009 to 2016, all our NAV developers did get this error message when compiling any report containing a WORD layout.
Niels-Henrik suggested to make sure to run windows update to see if that might fix the issue. And it did! At least ... on my laptop and our RAS development server. Unfortunately the issue continued for a couple of colleagues on their own laptop. As it wasn't a show stopping case so far we haven't paid much attention to it since then.
But last Sunday ... it hit me again. Arggggg. [8o|] And I needed to get the WORD reports working! As all updated had been installed on the Azure machine and having not a lot of to time to go and search for a solution, I decided to create a new machine to see if that would work fine.
"And of course it would have the latest NAV 2017 CU!", my mind ran.
YES, the WORD reports compiled. Again issue solved. But not for long as on Tuesday morning when wanting to run my WORD report example, the same error stopped me. [:@] [^o)] [:(]
"No time to fix it, pal." So I left it for later, already considering to create, once again, a new Azure machine during evening hours. Nevertheless I had quick look in the Event Log, showing:
---------------------------A call to Microsoft.Dynamics.Nav.DocumentReport.WordReportManager.MergeWordDocument failed with this message: Could not load file or assembly 'DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.---------------------------
"A corrupt DocumentFormat.OpenXml assembly?" I wondered, "Let's find out later."
That evening some more important work had to be done first, being, among others, the preparation the Data Upgrade demo for the next course day. The TableSyncSetup part ran as a charm. The real data upgrade part unfortunately didn't, and stopped with an error:
"Great, that's what I needed just now." [+o(]
"The application will close?" Nope, my NAV development Environment was still running; likewise the NAVCSD Service Tier. What was happening?
Looking at the Event Log I was quite surprised to read:
Exactly the same as with the WORD report issue.
"So solving this would in one go solve two issues," I thought out loud.
Googling around I found some reference to the Open XML SDK 2.5 for Microsoft Office, which I knew is one of the prerequisite components on the product NAV DVD: $\\Prerequisite Components\Open XML SDK 2.5 for Microsoft Office.
"Aha, lets reinstall and see."
YES, both the WORD reports compiled and the data upgrade ran without an errors! [Y][B]
Maybe this post will save you the searching I had to do.