Could not load file or assembly Microsoft.Dexterity.Bridge.dll or one of its dependencies – Dynamics GP

When developing Dynamics GP addins, the above error can occur for a number of reasons. It generally means what it says, the referenced assembly is looking for a resource it can’t find on the available search locations. If this is encountered whist developing a Dynamics GP addin while attempting to run the addin as an application outside of GP (say in debug from Visual Studio), then this error may well be encountered. What the developer may find odd is that it will work when ran from GP as an addin. Why is this so?

Could not load file or assembly Microsoft.DexterityBridge.dll

The “bridge dll” is the eventing route between GP and .NET applications (including addins) but it has other dependencies from the dexterity shared components. These are required to be present on the standard system environment paths searched when looking for dlls (search online for dll dependency search paths for more info).

When the addin is ran normally, as an addin by the Dynamics  GP process, the dependencies are provided by Dynamics GP process, from the process’s application folder. When running a free standing GP app, from the debug folder of Visual Studio, then the dependencies must be made available to the application through putting the dlls in the .net application’s folder (or other path that will be searched).

By placing TNTLIB.dll and DDAPI.dll into the bin folder should solve the problem. Strictly speaking xdll32.dll and Bidi32.dll should be included too (search online for stand alone Dexterity applications). In Visual Studio this can be achieved consistently by including the files in the project and setting them to copy to output. However it may be preferable to only do this for debug builds, that should be possible with Visual Studio post build steps or manually. 

The following are the files that should be included if running stand alone.

File Description
Tntlib.dll Library used by other dlls and executables
Ddapi.dll Data Dictionary API –provides access to Dexterity dictionaries
Bidi32.dll Additional dependency for dexterity  (My guess is: BiDirectional Convert Ansi To Oem code page, I think it converts extended languages that go left to right and right to left to oem code page characters and back again)
Xdll32.dll Dex gateway to other 32bit dlls

Just as a reminder, we should already be familiar with the usual .NET dlls required for .NET addins that would normally be referenced:

File Description
Microsoft.Dexterity.Shell.dll .NET managed shell
Microsoft.Dynamics.Framework. UI.Navigation.dll .NET navigation
Microsoft.Dynamics.Framework. UI.WinForms.Controls.dll .NET windows controls.

Please comment if you found this useful – motivates me to keep blogging…

Fabrikam Day 12th April 2017

Around the world people are posting photos of local landmarks and a #FabrikamDay banner, just for fun and to celebrate a sense of community around our product, Microsoft Dynamics GP.

Here is my contribution in front of The Angel of the North

FabrikamDay  - North East England

The date is a random date that was in the future, chosen to be used for the test company data in Dynamics GP.

fabrikam date

For more information on this read
Fabrikam Day! post by Amber and the

Post by Njevity To Go
Attention Dynamics GP Customers and Partners: We Need Your Help to celebrate Fabrikam Day!

VST Controls®™ for Dynamics GP Visual Studio Tools development

I’m so glad the day has finally arrived where I can talk about this innovation, I think this is one of the coolest things in .NET development with Dynamics GP for some time. I have been restless  to give it a go since I was first told about it.

What is the fuss about?

Last night VST Controls 1.0 was released. This is a really cool FREE .NET developer control library from Envisage Software (makers of PostMaster) & Precipio Services. When I say control library, it is actually a helper tool (provided as a .dll for GP 2013+) that allows any standard windows visual controls to be layered on a Dynamics GP form, and for the GP addin to communicate to those controls.

.NET development on Dynamics GP is limited to the standard set of dexterity controls that GP provides in modifier. Today users take for granted and expect as standard to be able to use more advanced controls with their applications.
Product image on item maintenance window

Above shows a product photo on the Item Maintenance form of GP. To a Dynamics NAV developer, perhaps excitement from being able to place a picture from the database onto the form seems odd? -trust me this is cool for us GP .NET developers.

VST Controls®™ solves some of the frustration caused by being restricted to the small subset of controls that GP as standard provides to the developer. Now with VST Controls on the scene, a developer’s creativity is released, as any control, including 3rd party controls can be placed on top of a GP form. Not only that, it is done with a few lines of code, so very simple to achieve!

Often I have wanted to be able to add say, a web browser control or picture control, even hyperlinks to GP forms, but have ended up having to “pop” a dialog window (a .NET form) to do so. This in many cases this upsets the flow that the user experiences as they traverse the user interface. By layering the “VST Controls” on top of the GP windows this should solve many of these issues.

Hey- this is not a substitute for the design time experience if the GP modifier designer suddenly supported .NET controls, but is the next best thing. There are also going to be some limitations to what you can do using this technique, already I've noticed issues around when the user resizes the GP form, but I’ll tolerate those limitations for what this opens up to me.

Go try it

So go try it – let your imagination go wild, it is totally $£€Freeno royalties  it is offered as a contribution to our GP community –so well done guys!

Screwed Allocations in Dynamics GP

SOP Entry

This is purely and observational post of a phenomenon we see in GP from time to time.

The telesales team perform data entry in the SOP screens at a lightening pace, tabbing through windows, hammering information into the screens very quickly while the customer verbalises the order to them. Over the years we regularly see inconsistencies between IV and SOP modules. Here is one that I captured that I’ve seen a few times.

The order default site is “1” and the user has no reason to sell from any location than “1”. There is no stock in location “5” nor any reason to look at that location. The order below is curious.


I would say some how the user has entered the item order quantity, accidentally, into the SITE ID field, every time the I see this the quantity ordered is the same as the accidentally entered site id. Thus my assumption.

That alone is not odd, but look further…


The stock has fully allocated to the order line.


However looking above that item has no stock (or ever has had) in location 5. Indeed the location allocation shows zero allocated.


Now above we look at location “1”, where the stock should have come from, and we see 5 allocated. If we drill into that allocation we find no documents allocated, however switching to location 5 shows our SOP document.

So it seems to me that the line originally was taking from location “1” and allocated, then somehow the user has managed to change the site ID without GP attempting to reallocate the stock. If it did reallocate it would have to back order the items as there is none to allocate in 5.

Then the order line has been saved with 5 as the site ID, leaving corrupt figures between SOP-IV modules.
I can only think there is a way or speed at which the events on the form don’t fire correctly or in the right sequence that allows this to happen.