For those of you who have done Visual Studio Tools integrations you are familiar with this tool already. The Dictionary Assembly Generator (DAG.exe) is a utility included with Visual Studio Tools for Microsoft Dynamics GP that creates a managed code assembly that provides access to resources in an application dictionary. As we move into the Service Based Architecture work with Dynamics GP 2015 this tool will play an important role.

 

The Dictionary Assembly Generator produces two output files that are used in your integrations: an application assembly and IntelliSense data file. The most important output is the application assembly. This is the managed code assembly that provides access to the resources in a dictionary. Each dictionary can have one corresponding application assembly. If you install the Visual Studio Tools SDK today available on the GP media under Tools > SDK, you’ll notice that there are several assembly files included. These are the assemblies for the core application (Dynamics.dic) and the other applications delivered with Dynamics GP. When developing integrations that use resources from these dictionaries, you always want to reference these digitally signed assemblies that were shipped with the product.

 

The Dictionary Assembly Generator is a command-line tool. To run, open a command prompt and set the current location to the folder where DAG.exe is located. From here you can view the command syntax by using the following prompt: dag.exe /?

 

 

The Dictionary Assembly Generator will build an application assembly for the main dictionary for an application or for the forms dictionary for an application. It uses the product ID to identify the dictionary for which you want to build an assembly.

 

So now that we’ve done a brief overview of what DAG is, let’s move on to what is changing with the tool in the GP 2015 release. When creating service procedures in the service based architecture one of the key steps is to define service metadata including setting the Service Enabled switch to TRUE. We also add a Service Procedure Metadata property which contains the relevant information for the GP Service to wire the procedure calls up to their URI endpoints. In addition to this, the procedure’s class definition will now contain a third invoke method which the service uses for parsing the request and building up the response.

 

 

All of this service metadata will be included and able to be referenced from an application assembly once it has been created via the Dictionary Assembly Generator. Running DAG on any dictionary containing at least one service procedure also triggers the generation of a Service Metadata Assembly (for example: Application.Dynamics.Metadata.dll) which contains service procedure metadata, some dictionary metadata, and referenced .NET library metadata for Discovery generation.

 

For those of you familiar with the assemblies generated today you may notice that for all procedures and functions, both global and form nested, parameters will be generated with their names rather than the current “inparam1, outparam2, inoutparam3” naming convention. One note though is that at present this is NOT true of parameter names in corresponding Event Args classes so that is something to keep in mind.

 

 

This is a brief summary of the significant work done to the Dictionary Assembly Generator for the Dynamics GP 2015 release particularly related to the service based architecture. These changes will enable wrapping the service metadata into an assembly that can be referenced in your integrations, enable discovery generation for your procedures as well as provide added ease of programming against generated assemblies. I encourage you to read the documentation which currently is installed with the Visual Studio Tools SDK and become familiar with how to generate an assembly for your dictionary if you have not used the tool before particularly if you are planning integrations utilizing the new service based architecture.