How to write Dexterity source which behaves differently for different versions

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):

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

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.

David