I've been doing a lot of work with Visual Studio Tools lately and find myself migrating more towards that from VBA. VSTools is not a replacement for VBA but in some cases can prove to be a more effective tool.

Modifying a Form in GP is often a simple thing to do with few repercussions if planned and executed properly. One drawback to a form modification is that you have to upgrade the modified forms even when applying service packs. This makes the service pack application and upgrade processes slightly more cumbersome. Not a big deal but another step in the process that in some instances you might be able to…

Steve Endow looks at his pain in Catching Unhandled Exceptions in .NET

I was doing a code review with a friend earlier this week and while we were discussing some application design topics, he noticed how I was coding calls to certain classes and offered a neat suggestion.  I'm far from a .NET guru, and am still constantly learning new syntax options since switching to C#, so this may be obvious to some/most .NET developers.

I often have classes that perform routine, discrete functions, such as getting preformatted dates, running regex…

This is a post about a very obscure topic that I normally would avoid, but since I spent the last several days dealing with it, I thought I would share the love.  If I ran into this problem with a very simple .NET eConnect integration, anyone could run into it.

I recently deployed three eConnect 9 imports at a client site, just like I've done with dozens and dozens of .NET eConnect integrations.

The client uses Citrix, and has two load balanced application servers for Dynamics GP.  To install my three imports, we had to install them on both of the Citrix servers.  The installs went fine, the apps all appeared to work well, and I thought my work was done.

Until the key business user launches one of the imports and gets an error.  The app doesn't launch, no windows appear, she just sees a "crash" error message.


After further testing, we find that the app launches fine on Citrix server #1, but gives her the error on Citrix server #2.  Exact same app.

I then check Event Viewer and see some arcane error messages related to the application crash.  They are basically generic .NET errors that don't provide any guidance as to the cause of the crash.


EventType clr20r3, P1 invoiceimport.exe, P2 1.0.2.0, P3 4c374d29, P4 mscorlib, P5 2.0.0.0....

I find out that these are very generic .NET errors that are occurring because I do not have an error…

In a recent Newsgroup posting, it was asked if Modifier and VBA (Visual Basic for Applications) and the Extender module worked for windows created as part of a Visual Studio Tools for Microsoft Dynamics GP Addin module.

The answer is that Modifier and VBA as well Extender…

(Update: Reader Stephan offers a more refined approach in the comments section of this post)

Recently I've been buried writing a VS Tools AddIn that has been a bit more complex than any previous AddIn that I've had to develop. Not terribly complex, just more involved than the typical AddIn widget that I write frequently. It's basically like a mini-module: A custom window, with a custom GP menu item, its own custom table, and lookups that query from GP tables.

And since the client uses C# internally, I've been transitioning to C# as well, so it's only the second project that I've done in C#.

Anyway, one of the things that I like to have on any user interface application that I develop is a visible build number. I have never used Help -> About dialogs (although maybe I should), so I just prefer to use a label or status strip to discretely show the app version.

Well,…

The Dynamics GP Blogster, Mariano Gomez, has begun an awesome series of posts about how a Dexterity developer can get started using Visual Studio Tools for Microsoft Dynamics GP.

Many of the concepts that make up the…

For the longest time I had been trapped in my own Microsoft Dexterity development shell and could not see why anyone would want to integrate to Dynamics GP with anything that is not Dexterity -- I am not referring to simple customizations here! After all, Dexterity is (and will continue being for years to come!) the native development environment of Dynamics GP. So, the next obvious question in my mind was, why couldn't .NET developers learn Dexterity? After all, we were here first! But, then I decided to spin the question around, why couldn't Dexterity developers learn .NET? Now, that's a challenge I like!!

In the next 2 weeks I will publish a set of articles showing Dexterity developers that it is possible to make a relatively smooth transition to .NET development with Visual Studio Tools for Microsoft Dynamics GP -- by far, the longest name for any Microsoft product, so we will shorten that to VST.

The similarities

What you will find as a Microsoft Dexterity developer transitioning to VST is that you can do a lot of the things you are able to do when building integrating applications: an integrating application can access the forms, windows, window fields, tables, and table fields in each dictionary. They can also access global variables, commands, procedures, and functions defined in each dictionary. So from a Dexterity developer's perspective you will be able to write the equivalent of triggers -- known as event registrations in VST -- on any resource in GP's dictionary or a third party…