For years I have been creating customizations for Microsoft Dynamics GP using a combination of Modifier and VBA. This has always worked well for me in the past with a few quirks and hiccups in VBA from time to time. I have created simple additional fields on screens, complex logic to enhance our customers business and many other types of projects. All of this has worked well, been easy to upgrade to the next GP version and been basically stable code for many years.
Recently the decision was made in my group to use Dot Net whenever possible in place of VBA. I am well versed in C# and the most things Dot Net, so this was not a concern to me. The decision was made for a number of reasons, one big one being the Dynamics GP web client, which does not handle VBA customization. Other reasons include better integration of source control, the much more robust features of the dot net framework and the separation of project into their own Dlls instead of a massive VBA project with many parts that are not related. There is also the DexUIForm class that you can inherit from on your windows forms which will allow you to make them have the same look and feel as the normal GP forms. Another big reason, for the most part new hires are not fluent in VBA.
All these reasons made good sense to us and we have been using Dot Net whenever possible, though we still maintain many VBA project from previous project and use Dexterity when Dot Not cannot do what is needed for a given project.
So what does all this mean, well it means that I have been using Dot Net more and more for my customizations and have picked up a few things that worth sharing. Many can be found in the SDK documentation provided by Microsoft, but if you are like me, you might go to the web before cracking open a PDF manual. If that is the case hopefully you will get some benefit from this article. Below are some general steps for creating a Dot Net based customization working in conjunction with modifier alter the appearance and function of an existing screen in Dynamics GP. This will cover topics that are separate from the web client, but add in projects can easily be upgraded to work for the web client.
It is assumed going forward that you have Microsoft Dynamics GP and visual Studio installed and functioning at least with the test company. You will also need to have modifier activated on your GP installation.
First thing is to download the visual studio tools SDK and install it.
This will give you all the needed libraries and project templates for creating a GP add in.
With this installed you will now have a project option for Microsoft Dynamics GP Addin project type.
Now set that dot net project aside for a moment, because in order to have your dot net project interact with modifications made to a Dynamics GP screen you are going to need a way to reference the screen changes. Your default project can reference and work with many windows, fields, and table in Dynamics GP, but in order to access any changes you have made to a window, adding new fields, buttons, etc, you will need to reference a library that contains your changes to GP via modifier.
Fear not, the good folks at Microsoft have taken care of this for you in the form for a little command line program called Dag.exe aka Dictionary Assembly Generator. This tool comes installed as part of the SDK for Dynamics.
You might notice that the path to the file in the screen capture of the command window is not pointing to the SDK folder, and is instead pointing to the installation location of my Dynamics GP. There is a reason for this. I copied it there. The reason for this is that if you try and run this from within the SDK folder you may encounter and error like “The dex.dic cannot be found”. Having it copied to the installation location of Dynamics GP resolves this issue.
The basic commands to use the tool are the dictionary ID, the Dynamics launch file (.set file), and a switch for the main for forms dictionary. An example command would be something like this
“C:Program FilesMicrosoft DynamicsGPdag.exe” 949 “C:Program FilesMicrosoft DynamicsGPDynamics.set” /F
In this example, 949 is the product Id for the dictionary that contains the screen we want to modify. “C:Program FilesMicrosoft DynamicsGPDynamics.set” is the path to the set file for our Dynamics GP installation. This file holds the list of modules and their dictionaries that GP will load at launch. By specifying /F we indicate that we want to interact with the Forms dictionary, this is the file that holds any modifications to the GP screens for this module.
So in order to reference our changes we will create a dll file using the dag.exe file and reference it in out visual studio project. First we need to make our changes in GP. This can be easily accomplished using Modifier to edit the layout of the GP screen in question.
You can access the Modifier menu from the tools menu on a GP window (Tools -> Customize -> Modifier, or Modify Current Window), or from the main Microsoft Dynamics Tools menu.
I prefer to navigate to the window in question and use the Modify Current Window option, mainly because it is easier to navigate to the window you want than to search though the list of windows in the modifier interface.
Using the modifier interface you can add fields, buttons and text to the existing window, resize the window and re-arrange change existing fields.
In this case let’s add a new local text field from the tool box in the modifier. Click on the icon in the toolbox, then click the location on the screen where this field should appear. You will want to adjust the properties of the field and at least change the field name as the default will be something like StringM42.
Now that we have changed the screen to meet our need, we can exit GP and then run the Dag.exe tool to create out dll that references these changes. When the tool finishes you will have a new .dll file in your GP installation folder. This new file will have a name like Application.FieldService.Modified.dll depending on the product Id specified in the dag.exe. In visual studio make a reference to this file. Now when you are working in visual studio code with the Dynamics GP objects you can access your modified form with the new field and attach to the field’s events and properties like you would any other standard Dynamics object but using the modified reference.
So your code would look something like this in C#
FieldServiceModified.Forms.ServiceContractBilling.NewField.Text = “Test Modified Field”;
Referencing the dll generated by the dag tool, and the modifications made using modifier to change the form. Now the code portion of the modification in GP can be taken out of VBA and we can use the Dot Net Framework and C# or VB.net instead. It should be noted that anytime you use modifier to change the form, you would need to generate a new assembly using Dag.exe to reflect those changes in your visual studio project, so make as much of the UI changes as you can before you start writing your Dot Net code.
In conclusion it may take a few extra steps to enable Dot Net and GP to work together, especially with modified forms, and there is a learning curve if you are used to using VBA, but with the help of the SDK manuals and articles like this one it can be accomplished, giving you the power of the Dot Net framework to use within your GP modifications.
WILL STAFFORD | .Net Business Solutions Team Leader
Will is responsible for the creation and maintenance of software customizations, reports and applications. He works on the entire development life cycle, gathering requirements, designing, coding, testing and providing support for applications. Will handles custom applications and the KTL suite of products. He has worked in the GP channel for over 15 years on integration and customization to Microsoft Dynamics. Will has extensive knowledge of Visual Basic, Visual Basic for Applications, MS SQL Server T-SQL, Crystal Reports and SQL Reporting Services. Will also works with the Microsoft .Net framework, including WPF, Web Services, Desktop Applications and Web Application development.
