Dynamic Code Blocks

Microsoft Dynamics GP & .NET technical Blog by Tim Wappat

Dynamics GP Visual Studio Addin - Open Form Parameters

How to open a native form, a pattern to follow

Opening a native GP form from VS addin

This post covers a self help pattern, to assist developers wishing to open a native GP form from .NET using Visual Studio Tools For GP addin.
An example is needed to work with, say it was required to open the Manufacturer’s Item Number Maintenance form from our .NET code:

image 

This form is normally only available from the Item Purchasing Options Maintenance Form but in this example it is required to launch it from our .NET code.

Identify the form name

Using the title caption from the form, go into Tools>Customise>Modifier to find the name of the form, or use the resource tool found under Tools>Resource Descriptions>Windows

IF using the resource tool, the product should be selected to which the form belongs, in this example Microsoft Dynamics GP, set Series Inventory, set View by display name.

image

Here we can see its called IV_MFG_Item_Nmbr_Mnt internally. Forms have display and internal names.

By typing in Visual Studio the window can be located by following intellisense, starting at the dictionary it belongs to (MicrosoftDynamicsGP) and taking out the underscores from the Dex name found above as it is typed.

Once the form is located, put a period after the form name to see what procedures it supports, typing “open” flushes out the procedures of interest.

image

It can be seen that to open the form, this form uses: OpenIvMfgItemNmbrMntProcedure

Intellisense also guides as to how to call it using  _Instance.Invoke
image

However, a familiar issue is hit at this point. The open procedure requires two parameters passing. What are the two parameters that intellisense is asking for? Luckily help is at hand, from the tooltip (see image above),

Invokes form procedure “Open_IV_MFG_Item_Mnt” of form “IV_MFG_Nmbr_Mnt”

Thus recalling that all that is happening here is a call down to procedures in the underlying dexterity code, we can find what we need to call this by checking the Software Developer Kit (SDK).

You of course have the GP SDK installed? – if not get it now…

Using the SDK to find parameters

Searching on the SDK folder, C:\program Files\Microsoft Dynamics\GP11.0 SDK\Content   for the start of the procedure name “Open_IV_MFG” a hit is returned in a file called “CoreForms_1100.txt”

Opening CoreForms_1100.txt, and search for the same term. The following text is found in the document …

------------------------------------------------------------------------
INVENTORY FORM PROCEDURE:  Open_IV_MFG_Item_Nmbr_Mnt
    of form IV_MFG_Item_Nmbr_Mnt
------------------------------------------------------------------------
in                       'Item Number'            l_item;
in                       'Item Description'       l_Description;

So the two parameters needed are Item Number and Item Description.

So now we call it like this:

MicrosoftDynamicsGpDictionary.IvMfgItemNmbrMntForm.OpenIvMfgItemNmbrMntProcedure._Instance.Invoke
("testpart", "testpart description")

Compile, deploy and you should find the form opens with the item selected!

 

Fix for Dynamics GP Add-In Initalization Error launching GP 2010,sp3

In this post we solve an initalisation problem with Dynamics GP add-ins

Problem

Building a new Dynamics GP 2010 client I experienced the following error on putting our customisations into the GP 2010 Addin directory. When launching the GP application, the application crashed out.

Microsoft.Dynamics.GP.BusinessIntelligence.BIReportDeploymentGP.dll: Method not found: ‘ClearCompanyListProcedure FormProcedures.get_ClearCompanyList()’.

 

image

Clue to my issue was in the forum posing here:
Login Problem in Microsoft Dynamics GP 2010- where MUFADDAL SHAKIR suggested that

removing Application.Dynamics.dll from the Addins folder resolved the issue

Ok it solved the issue but will mean that dll is not available to use which is no good for me, however it immediately occurred to me what had happened. In my GP application directory there is a copy of the current Application.Dynamics.dll, Checking its version it was 11.00.0363.000,

imageimage

then checking the one I was referencing in Visual Studio, that due to the deployment was also  the one held in the addins folder, I found it was version 11.00.0218.000. Classic file version control issues had struck! Somehow, I’m not certain how, an old version of the dll was still in source control and had been pulled into my machine’s addin folder in development.

Solution

Hence when the old dll was replaced by the new, everything worked as it should again. I guess this is a new method added into dynamics dic during one of the releases what could not be found.

Architecture

Just to remind you & me of the key dlls involved in visual studio dynamics gp Add-ins:

Microsoft.Dexterity.Shell.dll Used by visual studio do draw the right looking UI to the canvas
Microsoft.Dexterity.Bridge.dll Events and resources bridge to application dictionaries
Application.Dynamics.dll (and others) Dynamics.Dic default assembly, representing the actual methods and events in that GP application dictionary.
A long list of which can be found in your application directory, see below screenshot, you reference what you use:image

Use the DAG.EXE to generate your own for modified forms…

All this is covered in: Visual Studio® Tools for Microsoft Dynamics® GP 2010 Programmer’s Guide

Also online: Architecture from msdn

Fix: Dynamics GP 2010 modify word template, File Not Found

What to do if you encounter the File not Found error when opening word templates in Dynamics GP

 

Template maintenance in Dynamics GP2010 fails

When in REPORTS>>Template Maintenance, after creating a new report from an original report, clicking on “Modify” caused a file not found exception on our install of GP.

"File Not Found: C:\DOCUME~1\USERXX\LOCAL~1\TEMP\file you were savingcreating.docx"

Solutions on the web GP community forums

  • Reinstalling Dexterity Shared Components
  • Upgrading to GP2010 SP2 or above

These solutions were not working for us. Between us we spent too much time running filemon and looking at debugger tool traces trying to track the problem down. The traces showed the template being created in the user profile temp directory with no error, but in reality it never got there.

Breakthrough

The server copy did work correctly. We spent some time between us trying to work out what the issue was and finally a colleague said something that made sense to me, so I checked out the theory.

I did a WinMerge check between the Add-in Directories (Addins subdirectory of GP application directory) on the working and failing machine and found the following missing files:

image

 

Copy the missing DLLs into the Adds folder

After copying all but the BusinessIntelligence dlls to the add-in folder of the previously broken install, the feature started working correctly again.

My guess is the managed storage dll is involved with the creating of the temp file… possibly.

Hence it would seem we’ve dropped these files as we have upgraded through the versions. We have our own Visual Studio Tools Addins in the add-ins folder. These are passed from version to version as we upgrade GP. My guess is these extra missing dlls got lost at some point causing the word template editing functionality to fail.

I hope this post has helped you get to the solution more quickly that we did.

Here is the working template in word

clip_image002

Dynamics GP Add in “Cannot load file or assembly Microsoft.Lync.Utilities”

Interesting post on the dependency Dynamics GP has on Lync runtime

GP Add in raised exception

After applying GP2010 SP3 my GP add in started raising an exception on windows forms that used Entity Framework (EF). The error reported was

System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Lync.Utilities, Version=4.0.0.0…"

…but I don’t use Lync…

But I know Dynamics GP does have integration with Lync. It had me puzzled for a while as I wondered why my form was causing this assembly to be required and attempting to load it. Eventually the penny dropped after studying the stack trace. The stack trace was mentioning about System.Reflection and System.Data.Metadata.Edm.DefaultAssemblyResolver.GetAllDiscoverableAssemblies().  I guessed there was some dynamic loading going on and got mislead reading up on MEF, thinking perhaps GP implemented it under the covers. I then hit lucky on Google with Craig Suntz’s blog that explained my issue. It is down to Entity Framework connection strings.

Entity Framework Connection Strings

In my EF connection string I was building my connection string like this from the SQL connection string.

Dim entityBuilder As New EntityClient.EntityConnectionStringBuilder()
entityBuilder.Provider = "System.Data.SqlClient"
entityBuilder.ProviderConnectionString = sqlBuilder.ToString
entityBuilder.Metadata = _
"res://*/Inventory.DAL.InventoryModel.csdl|res://*/Inventory.DAL.InventoryModel.ssdl|res://*/Inventory.DAL.InventoryModel.msl"
Return entityBuilder.ToString()

Notice the “res://*” bit, the Metadata reference. The files are embedded into the assembly as resources and this Metadata property is the pointer to them. Specifying * instructs a reflective search through all assemblies (even if not yet loaded)  that are referenced by the application, looking for the resources.

I guess that as Lync SDK was referenced by GP 2010 my attempt to create the connection was causing the Lync assembly to be loaded in order to check it for the meta file resource. The consequence of this is that we got an application exception as that assembly does not exist on the machines in our organisation.

Solution

The solution is to explicitly specify the assembly name that holds the resource as shown in the next code snippet. Making this exact reference is more efficient by it preventing unnecessary loading of assemblies and thus preventing the error . This is interesting as I’d experienced a performance hit on these windows vs ones not using EF. I assume some of that was down to this attempt to load all the assemblies.

Dim entityBuilder As New EntityClient.EntityConnectionStringBuilder()
entityBuilder.Provider = "System.Data.SqlClient"
entityBuilder.ProviderConnectionString = sqlBuilder.ToString
entityBuilder.Metadata = "res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.csdl|res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.ssdl|res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.msl"
Return entityBuilder.ToString()

Solved

After recompiling and then deploying to the GP add in folder, my problem went away. I suspect if I spent some more time on this that the Lync assemblies are stuffed into the Global Assembly Cache by the SP3 installer, as we do copy deployments to the client machines we will be missing those assemblies. Hence not everyone may suffer this issue when using add ins if you run the full installer. However this guesswork needs researching and I’ve not got time right now to investigate.

About MEF (Microsoft Extensibility Framework)

In my Google search of the issue, it looks like you can get issues around MEF with dynamically loading assemblies, so for those of you finding this post through Google and not using Dynamics GP, then that might be a term to try on Google for a solution in your scenario.

Below is the original error

Raised by by Add-in for those still with an interest…

clip_image002