Dynamics GP VSTools Addins Not Loading

Last September I picked up a Visual Studio Tools 9.0 case that was pretty interesting that I will share today.

The ISV had a custom addin they had developed and worked fine on their test servers (doesn't it always?).  Now when deploying the addin at the customer site; they found that their Extras menu item wouldn't display for the Dynamics GP form that it should.  Actually, none of their Extra menu items would show - they had several.

To troubleshoot, we started with the obvious.  Is the addin in the \Addins folder?  Well - yes it was.  So scratch off the obvious.

So next we verfied that at least SP1 was installed as that was the version of the first release of Visual Studio Tools.  The dictionary version was at least SP1.  But what if the runtime wasn't 9.0.68 (sp1) for some reason?  So we checked and it was actually like 9.0 SP3 or 4 at that time.  Then we checked the version of the Microsoft.Dexterity.Bridge.dll thinking maybe it was a pre-release Beta version or something.  No, it was the correct version - the only version released.

So from what we could see, there wasn't any reason why the dll wasn't being loaded.  And if it was loaded then the Form trigger for the Extras menu should work.  The machine was XP and Dynamics installed to the local c:\ drive but I don't recall if it was installed into the Program Files path or not.  Shouldn't matter, however, since that path is only "special" under Vista, Windows 7, and Windows 2008/R2.  So that all seemed OK as well.

To see if it was something specific with this particular addin - we had the ISV compile the Estimate Freight sample and install it.  It too failed to display its Extra menu in the SOP Entry window.

Puzzling and more puzzling. 

My next thought was perhaps there was some kind of permissions error that was somehow interfering with the dll being loaded.

We downloaded and installed the Process Monitor tool from the Microsoft Sysinternals site and set it to restrict to the Dynamics.exe process.

After launching Dynamics and getting to the Login window where all Addins would have been loaded, I stopped the trace.

Looking through it, nothing jumped out right away.  Just normal items that I've seen many times.

And then I saw it.  Channeling my inner Sherlock Holmes I exclaimed "Hello, what is this?".

What I noticed in the Process Monitor trace was that the even though this was a full local install, the Dynamics.dic was being read from:

\\server\share\Dictionaries\Dynamics.dic

Well, unusual but that should be OK.

But then I noticed this:

\\server\share\Dictionaries\Addins\*.dll

OK, we're looking for all the dlls on that shared drive in the Addins folder.  And something interesting to me and that I wasn't aware of - the Dynamics.exe runtime apparently is looking for the Addins folder next to the Dynamics dictionary.  I had always assumed that it would look next to the runtime folder and not the dictionary.

Looking at the Dynamics.set file, I did see that all of the dictionaries - Dynamics.dic as well as the forms and reports - were pointed to the server shared folder.  Looking at the server shared Addins folder, there were no dlls so I guess then it wasn't a surprise the triggers weren't registered. 

We quickly then changed the Dynamics.set file to point locally and restarted Dynamics.  This time the triggers registered themselves and worked correctly.

So it would seem that the solution would either be to copy the dlls to the server addins folder or map the Dynamics dictionary locally (which is best practice anyway).

On 2nd thought, I don't think copying the dll to the UNC share would (easily) work.  The reason is that by default .NET assemblies aren't trusted if they are outside of the local zone.  So even a UNC path that is to the local machine wouldn't be trusted.

To test this theory, I modified my Dynamics.set on my GP 2010 install to be:

//prot309/c$/dynamics2010/Dynamics.dic
//prot309/c$/dynamics2010/Data/Forms.dic
//prot309/c$/dynamics2010/Data/Reports.dic

I launched my Dynamics GP 2010 using the modified Dynamics.set file.  I received the error I expected to see:

ConfigTest.dll: That assembly does not allow partially trusted callers

If I wanted, I could adjust permissons to trust this assembly using the control panel applet "Microsoft .NET Framework 2.0 Configuration".  But I think that I'll reset my set file to be local again instead.

Best Regards,
Patrick Roth
Microsoft Dynamics GP Developer Support