Developing for Dynamics GP

by Microsoft Dynamics GP Developer Support Team (Fargo, ND, USA)

Dynamics GP VSTools Addins Not Loading

Dynamics GP VSTools Addins Not Loading

Rate This
  • Comments 5

Patrick Roth - Click for blog homepageLast 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 

  • Hi Pat

    Running with the main application dictionary Dynamics.dic locally will give better performance and less network congestion as we don't have large amounts of dictionary resources being transmitted over the network.

    David

  • Of course that is the case and noted above as a Best Practice.  However you could do this if you wished.

  • Same thing with the dex.ini file. We've got one user that was running GP 9, completely off the network. Once we moved *just* the dex.ini file to the local machines, we got about a 30-40% speed increase. Thank goodness dynamics.exe takes dex.ini as a parameter!

  • Hi Steven

    I would recommend having everything (except the data) local, even customizations.

    Having customizations synchronised locally, is better than using shared network resources.  See my posts on the topic:

    blogs.msdn.com/.../automating-distribution-of-customisations-part-1.aspx

    David

  • Posting from Mark Polino at DynamicAccounting.net

    msdynamicsgp.blogspot.com/.../dynamics-gp-vstools-addins-not-loading.html

Page 1 of 1 (5 items)
Comments Information

PLEASE READ BEFORE POSTING

Please only post comments relating to the topic of this page.

If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.

Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post