Tuesday, April 14, 2009

Reset GP During AddIn Testing

Dynamics GP AddIns are great. You can use Visual Studio and your preferred .NET language to create powerful enhancements for Dynamics GP. And the AddIns are neatly packaged in a DLL file that you simply need to copy into the GP AddIns folder.

But, of course, there are some downsides, one of which is testing and debugging. One issue is that if you need to modify your code, you need to recompile the DLL file, close GP, copy the new DLL file, then re-launch GP. It's tedious and time consuming.

If you aren't accessing any GP windows or Dynamics objects, you can write a wrapper EXE to test your DLL independent of GP, but if you are using Dynamics objects, you need to update your DLL and test in GP. After closing and launching GP a dozen times, you'll be fed up.

Following on my solution for resetting GP when testing with Integration Manager, I've created a very similar solution for testing GP AddIn DLLs.

I needed the following:
  1. Close GP
  2. Copy my new DLL to the AddIns folder
  3. Launch GP and login again
For this particular project, I'm developing on Windows 2008 with SQL 2008 and GP 10, so I noticed a few things behaved differently and had to make a few minor differences to make my prior script work. I didn't note all of the differences, but the primary issue was getting GP to automatically launch and run the login macro using the Start command, which I'm guessing is something about Windows 2008.

You will want to complete all of the same preparatory steps in my prior post, and then use the scripts below.

I used the following batch file:

C:\pskill dynamics.exe

sqlcmd -S SQL2008\GP10 -E -Q "DELETE FROM DYNAMICS.dbo.ACTIVITY WHERE USERID = 'sa'"

xcopy "C:\Users\sendow\Documents\Visual Studio 2005\Projects\MyAddIn\bin\Debug\MyAddIn.dll" "C:\Program Files\Microsoft Dynamics\GP10\AddIns\" /Y


start Dynamics.exe "C:\Program Files\Microsoft Dynamics\GP10\Dynamics.set" C:\Login.mac



And here is the login.mac file that worked for me: (change the password and company ID to suit your environment)

Logging file 'none.txt'
CheckActiveWin dictionary 'default' form Login window Login
MoveTo field 'User ID'
TypeTo field 'User ID' , 'sa'
MoveTo field Password
TypeTo field Password , 'password'
CheckActiveWin dictionary 'default' form Login window Login
MoveTo field 'OK Button'
ClickHit field 'OK Button'
NewActiveWin dictionary 'default' form 'Switch Company' window 'Switch Company'
ClickHit field '(L) Company Names' item 1 # 'Fabrikam'
MoveTo field 'OK Button'
ClickHit field 'OK Button'
NewActiveWin dictionary 'default' form sheLL window sheLL
NewActiveWin dictionary 'default' form sheLL window sheLL
ActivateWindow dictionary 'default' form sheLL window sheLL



Notice that on the last line of the batch file, I had to specify the full path to the Dynamics.set file, even though it is in the PATH variable, just like Dynamics.exe.

Once the batch file has been created, just create a shortcut on your desktop or a shortcut in your QuickLaunch toolbar.

Now with a single or double click, GP is closed, your recompiled DLL is copied to the AddIns folder, and then GP is launched.

It's not quite as easy as just clicking Run in Visual Studio and debugging directly, but it saves time and alot of hassle.

UPDATE: One caveat that I forgot to mention on my prior post as well as this one: You will want to make sure and close all GP windows before running the batch file, otherwise you can end up with invalid records in your DEX_LOCK table. If you don't want to close the windows, you could add an additional line to the batch file to delete the records in DEX_LOCK.

Of course, these scripts and this process are intended only for use on an isolated development workstation and should not be used in production.

2 comments:

  1. In Visual Studio you can simply set the properties of the startup project (the GP Addin) on its Debug Tab to start Dynamics GP as the the External Program (i.e. C:\Program Files\Microsoft Dynamics\GP\Dynamics.exe). Then when you start Debugging VS will automatically launch GP and hookup the debugger to it. You can't tell GP what SET file to use so when it starts it will ask you for it, just navigate to the GP folder and select it (VS will remember the folder on subsequent debugs). Then you just logon normally. Great thing with this method is it allows debugging code that you have at launch such as hooking up GP Menus. Also, I typically have VS copy the GP Addin DLL for me to the GP Addin Folder as a post build job.

    ReplyDelete
  2. Thanks for the tip.

    It sounds almost like a tie to me. Your approach copies the DLL, attaches to the process for debugging, and launches GP. But it doesn't close GP, select the set file, or login automatically.

    While the approach I outlined quickly kills GP, copies the file, relaunches GP, handles the set file, and logs in automatically, but does not automatically attach VS to the process. Since I find the close + launch + login to be the most time consuming / tedious elements, I guess I wanted to automate those steps for sure.

    Perhaps there is a way to combine both approaches. I guess the next time I write an AddIn, I'll see if I can merge them.

    ReplyDelete