Running Dexterity Applications in Debug Mode (Dynamics GP)

Coding

Recently, I was asked by a client to list out the steps to run a Dexterity-based customization in Test or Debug mode. The client had indicated that he “has never been able to run” his customizations in Test mode and asked for my help.

Since I have not had issues running the client’s GP2016 R2 Dexterity-based customizations in Debug mode, the first thing I asked for was a copy of the error that the client was receiving when attempting to launch the customizations in test mode from the Dexterity IDE (via Debug ->Test). Below are the screen captures of the errors that were received:

Error Message in Dexterity IDE

The above error is indicative of a permissions issue whereby the Dexterity system is referencing external dictionaries that are not yet loaded. However, since the error message was being presented prior to logging into GP, my initial thought was that the wrong version of Dexterity was being used. There was no proof of that; it was a just a theory.

Clicking on OK generated the same error dialog again, and clicking OK one last time opened the system login dialog box, but without a listed server DSN.

Error Message in Dexterity IDE - System Login

At this point, I was getting more dubious, especially since I was able to launch the development dictionary in Debug mode with no error messages and with a clean login into the GP test company. Upon discussion with the client, I found that he was using the RTM version of Dexterity and not the matching 2016 R2 version of Dexterity, which is 16.00.0034.000. Although a minor issue, it is extremely frustrating as a developer when a debug or test mode fails without any apparent root cause. In the case of testing Dexterity customizations in test mode, I saw similar behavior with GP2013 and its Dexterity version, since 2013 R2 does not work properly with the Dex 2013 RTM version. So, if you see similar behavior with your Dexterity customizations in test mode—but they work fine after they are chunked up and extracted—then you likely have a version mismatch between the installed GP runtime engine and the Dexterity version.

6 Best Practices When Testing Dexterity Customizations:

  1. Always use a dedicated Dex test user that only has access to the core GP modules. Remember, you will not have access to third-party dictionaries in Dexterity test mode. Further, this user should not be a Poweruser.
  2. Ensure the dedicated Dex test user belongs to its own Alternate/Modified Resources ID so that all stock resources can be assigned to the ID and not necessarily to the test user. This allows multiple test users to be set up in a multi-developer environment.
  3. Never use sa for testing as any SQL security errors will be masked by the system administrative privileges. Using the Dex test user will also validate that any GP-related permissions errors are reported.
  4. In the Dexterity code, have separate code paths when the customization is executed in test mode via the isTestMode () system call. This is especially helpful if the code depends upon third-party dictionaries in a runtime multi-dictionary environment.
  5. Do not create a chunk file until all possible unit tests have been performed in Test mode with full code coverage.
  6. As mentioned, ensure your Dexterity runtime environment matches the GP runtime version.

If you have questions or need some assistance, visit our support page for more help.

Leave a Reply