How to write Dexterity source which behaves differently for different versions

David Meego - Click for blog homepageThis is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.

As a developer there are often times when I need to write and maintain code which works for multiple versions of Microsoft Dynamics GP.  A great example of this is the Support Debugging Tool for Microsoft Dynamics GP.  This tool has been written for versions 8.00, 9.00 & 10.00 and will be maintained for all currently supported versions of Microsoft Dynamics GP as we go into the future.

The method I use to work across multiple versions is to open one instance of Dexterity for each version and then whenever I add or update a base resource, I make the change in all instances.  This is for resources such as Data Types, Fields, Tables, Pictures, Constants, Messages etc.  This ensures that the resources stay current.

Whenever I need to work with Forms, Reports, Functions and Procedures, I check out the resource in all versions.  Then I only work in one version until I have the code working as desired.  Then I export the resources from the version I was working with and import them into the other versions. Finally, I can compile the dictionary, test and check in the resources.

This method works great …. until you need different code for the different versions.  For example: Version 10.00 needs additional code for working with the new security model to add Security Task and Security Roles to the table.  In the Support Debugging Tool, the new Security Information window in build 10 needs to handle the security tables completely differently for v8.00 and v9.00 versus v10.00.  If I have different code in v10.00, how do I ensure I don’t overwrite it when copying code from another version?

The answer is simple (once you know how):

The source code is actually exactly the same for all versions, but uses conditional compilation based on the version it is being used with. Dexterity includes a number of pre-compiler commands which can be used to control the compilation of code.

I use a set of constants which describe the version and build of my code, they are shown below (pre-fixed by MBS for Microsoft Business Solutions, you can use your own company abbreviation):

Constant Name Description Example Value
MBS_PROD_MAJ The Major Version number of the Dynamics GP release 10
MBS_PROD_MIN The Minor Version number of the Dynamics GP release 0
MBS_PROD_BUILD The Build number of the customization dictionary 10

Note: I am only using the MBS_PROD_MAJ for my example code, but you could have conditional compilation based on a build number which could then handle calling a procedure which has changed parameters in a service pack of the same version.

Code Conditional Compilation Example#if MBS_PROD_MAJ >= 10 then
{ Version 10.0 or later Code goes here}
{ Version 8.00 and 9.00 Code goes here }
#end if

The Hash (#) symbol must be the first character on the line. For more information you can look up “Compiling” in the Dexterity help and then select the “controlling from scripts” or “script preprocessor” section.

Hint: If you are writing form level code which needs to use tables which exist in one version and not in another, you cannot attach the tables to the form as they are not available in all versions.  So, in this case you can call global functions and procedures from the form and use conditional compilation.  By using global level functions and procedures, you can access the tables without needing to attach them to the form.

I hope this Best Practice method is useful to you.


This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on

One thought on “How to write Dexterity source which behaves differently for different versions

Please post feedback or comments

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.