#Dexterity Development Environments – Part 1: Installation

This article has been a long time coming and is the first of a series of articles on how I set up my machine for developing Dexterity applications across multiple versions.

I promised I would detail how my system is set up a while back at the reImagine 2015 conference and had never got around to writing the article until now.

Disclaimer: This is the Musgravion principles of development machine setup. It is not the only method but it has worked for me for many years and has been fine tuned during my career. Feel free to use it if it works for you.

Background

I currently have seven versions of Microsoft Dynamics GP and Dexterity installed on my system; GP 2010, GP 2013, GP 2015 and GP 2016 as well as the R2 releases for GP 2013, GP 2015 and GP 2016.

When I develop products I write with a single code base for four versions; GP 2010, GP 2013, GP 2015 and GP 2016. I use conditional code and conditional compilation to handle differences between versions and test on both RTM and R2 releases to make sure everything works.

For my SQL Server install, I am using SQL Server 2012 as this version works for all the versions of Microsoft Dynamics GP I am using. Starting from GP 2013, you can specify the names for the system database and sample company database. This functionality makes it possible for a single SQL instance to support all the Dynamics GP versions I want to use. Prior to allowing Named System Databases, you would have to use multiple instances of SQL Server.

I am using Microsoft Visual Source Safe 2005 for source code control. Source Code Control should be used by all Dexterity developers and not just when upgrading. The ability to cancel changes you have made and roll back to a last checked in version is invaluable. It also allows multiple developers to work on a single development at the same time. With Visual Studio Team Services (think Team Foundation Server in the cloud), you can even have multiple remote developers working on the same project.

Microsoft Dynamics GP

I have installed all the versions of Microsoft Dynamics GP I wanted in the order they were released. To allow all the versions to co-reside on the same machine, I use the following naming conventions:

* Optional install used for compatibility testing

Make sure that each version of Microsoft Dynamics GP has been completely set up, launched and logged into.

Microsoft Dexterity

I have installed the versions of Dexterity to matched the installed versions of Microsoft Dynamics GP. To allow the versions to co-reside on the same machine, I use the following naming conventions:

* Optional install

To prepare the Dexterity environment for use, copy the Dex.ini file from the C:\DynXX00\Data folder to the C:\DexXX00\Data folder.

Open the Dex.ini copied into C:\DexXX00\Data with Notepad.exe and locate the DexHelpPath setting. If it exists, edit the setting to point to the Dexterity folder or add a semicolon at the beginning of the line to comment out the line and let the default location be used.

For more information, see the KB Article I created back in March 2008:

• How to set up the development environment when you use Dexterity in Microsoft Dynamics GP

Stay tuned for the next article on setting up individual Dexterity development projects.

David

This article was originally posted on http://www.winthropdc.com/blog.

Filed under: 2010, 2013, 2015, 2016, Development, Dexterity, Dynamics, GP, Microsoft, SQL Server Tagged: Dexterity, GP 2010, GP 2013, GP 2015, GP 2016, SQL, VSS