Normally the "installation" of a Dynamics GP add in is very simple--just copy the DLL to the AddIns directory, then launch GP, and it works. It's a wonderfully easy and reliable deployment process.
However, with Dynamics GP 9, there are two small caveats. First, the Visual Studio Tools runtime must be installed. Second, the AddIn directly does not exist by default, so it must be created. Pretty simple tasks.
The client dutifully installed the VS Tools runtime, then created the AddIns sub-directory in his GP application directory. He then installed the third party product, which copied three DLLs to the AddIns directory.
But when he launched GP, the AddIn didn't load.
He then tried uninstalling the add in, uninstalling VS Tools Runtime, and then reinstalling both. Nada.
Thinking that maybe there was a problem with the third party add in, we tried the sample Freight Estimator add in. But even that wouldn't load.
We then checked permissions, but he was logged in as a local Administrator on the Server 2003 machine, and he was using the sa login for GP. We even checked directory permissions on the Dynamics GP application directory and the AddIns directory, and opened up permissions on both of those to see if that helped. Still wouldn't work.
We then checked the path of the icons used to launch GP to verify that it was the same directory where the AddIns were installed. All looked good.
Having exhausted all of the standard troubleshooting steps, we submitted a support case. The support engineer had us verify all of the same tests to make sure we didn't miss anything. He then sent us a simple test add in DLL that would display a message box as soon as it loaded, but even that didn't work.
The client finally had a streaming session with the support engineer who eventually used the Process Monitor tool to trace the behind the scenes GP activity. In the 137,000 records that scrolled by, the engineer eventually found a strange error.
Dynamics GP was getting a path not found error when trying to read and write to the AddIns folder. What was strange was that the path that was listed in the Process Monitor log was \\remoteserver\data\Apps\GP9\Dictionaries\AddIns.
The very sharp engineer then took a look at the client's Dynamics.set file. Everything looked normal, except for one line. The Dynamics.dic file path was set to the same network share as the Reports.dic and Forms.dic. For some reason, the client's IT staff had made the Dynamics.dic a shared dictionary.
Putting the two together, he noticed that Dynamics GP was looking for an AddIns directory in the same location as the shared Dynamics.dic file. He, and I, thought (assumed?) that GP looked for the AddIns subdirectory in the same location as the Dynamics.exe and Dynamics.set, but apparently this is not the case. It seems that GP expects the AddIns subdirectory to be in the same directory as the Dynamics.dic file. Normally, the Dynamics dictionary is located in the local GP application directory, and there is no reason to share it, so that statement is usually true--but only by coincidence.
Having deduced this much, they modified the Dynamics.set file to point to the local Dynamics.dic, and viola, the AddIns suddenly started working.
Kudos to the Dynamics GP developer tools support team for tracking this one down!
No comments:
Post a Comment