Freigeben über

Microsoft Dynamics GP 2013 SP2 - Things to consider when moving your Visual Studio Tools add-ins to the web client

  • Artikel

Alice Newsam - Click for blog homepageOne of the features included in the Microsoft Dynamics GP 2013 Service Pack 2 release was the ability to now render Visual Studio Tools customizations in the web client. For those of you that missed the overview session of this feature at the recent Microsoft Dynamics GP Technical Airlift 2013, I thought I'd share some "things to consider" in a post. 

For those not familiar with the VS Tools functionality, it allows ISV developers to create integrations for Dynamics GP using the .NET framework. Previously this was only available on the desktop client. However, with the release of SP2, the functionality of the tools to support add-ins that run in the web client, while reusing existing code, was extended.

There are two approaches available in the first release of this feature including dynamic rendering and custom code.  For more details on those, Mariano Gomez, (aka: The Dynamics GP Blogster) posted two articles recently on this including one on preparing your development environment and another on rendering winforms in the web client. For those of you preparing your existing add-ins to move to the web client or those pondering creating new add-ins, I wanted to share some tips and things to consider to make the process the smoothest it can be.

Add-in Loading Changes

With the release of Dynamics GP 2013 RTM, you may be aware that changes were made to where add-ins needed to be placed in the client directory as well as updates needing to be made in configuration files.  As part of the SP2 feature updates, we added an attribute called "SupportedDexPlatforms". This attribute, which you add to the class that implements the IDexterityAddIn interface, allows all add-ins to be placed in the Addin folder of the client and enables the application to know when to load each add-in.  You can specify if you want an add-in to load in the desktop client, web client or both.

[SupportedDexPlatforms(DexPlatforms.DesktopClient | DexPlatforms.WebClient)]
     public class GPAddIn : IDexterityAddIn
     {

Helper Functions

To facilitate VS Tools functionality on the web client a number of helper functions were added to a form in the Dynamics dictionary called syVisualStudioHelper.  Via the assemblies created by the dag.exe tool, integrations can access these functions.  One such function is called DexRuntimeGetClientType() . It allows you to determine which client the integration is being ran in. This is particularly helpful if you have cases where you want one block of code executed for desktop client users and another block of code for web client users.  If you are going to need this information throughout your add-in, consider calling it once in your Initialize method to simplify the code and make it more efficient.

Modal Dialogs

In a Visual Studio Tools integration that works with the Microsoft Dynamics GP desktop client, it’s common to use the MessageBox class from the .NET framework to display modal dialogs. However, this class is not supported on the Microsoft Dynamics GP web client. Instead, you should use calls to the appropriate "helper" functions in the Dynamics dictionary to display modal dialogs such as:

  • DexAsk()
  • DexError()
  • DexWarning()
  • DexGetstring()

Closing Forms

Always use the Close() method on the form class to close the forms within your integration. This method will send the appropriate messages between the web client and server and allow the form to be properly garbage-collected by the .NET runtime.  Do not use methods like Dispose() to close a form in your integration because you will likely encounter errors in the web client. This happens because the form is garbage-collected but the web client runtime engine doesn’t know that the form has been closed. We termed these windows "zombies" in our testing because they started randomly losing parts and acting strange!

Local File Access

When your Visual Studio Tools add-in is running on the Microsoft Dynamics GP desktop client, it has access to any location in the local file system for which the user has permissions. However, with the web client, a Visual Studio Tools add-in running on the server has access to only the temporary folder for the current web client session. If your Visual Studio Tools integration will run on the web client and will perform file operations such as writing to temporary files, it must do these actions in this temporary location. 

Two new helper functions have been added for this:

  • DexFileGetTempDirectory()
  • DexFileLaunch()

We are excited to expand the functionality of the Visual Studio Tools SDK to facilitate integrations in both the Dynamics GP desktop and web client environments.  As you start to use the new features, I encourage you to review your current add-ins for these things or keep them in mind when creating new integrations to make the implementations more efficient.

Happy coding!

Alice

Comments

  • Anonymous
    October 03, 2013
    Alice, Good to see you posting and thanks for the mention. Just couple clarifications:
  1. When you say, ""SupportedDexPlatforms". This attribute, which you add to the class that implements the IDexterityAddIn interface, allows all add-ins to be placed in the Addin folder of the client and enables the application to know when to load each add-in", I just wanted to mention that the term "application" here refers to the Microsoft Dynamics GP runtime engine, DYNAMICS.EXE, for the rich client, or in the case of the web client, Microsoft.Dynamics.GP.Web.Services.Runtime.Process.exe.
  2. "To facilitate VS Tools functionality on the web client a number of helper functions were added to a form in the Dynamics dictionary called syVisualStudioHelper.  Via the assemblies created by the dag.exe tool, integrations can access these functions.  One such function is called DexRuntimeGetClientType(). It allows you to determine which client the integration is being ran in. This is particularly helpful if you have cases where you want one block of code executed for desktop client users and another block of code for web client users.  If you are going to need this information throughout your add-in, consider calling it once in your Initialize method to simplify the code and make it more efficient.". I would also add that you can determine what client is running by checking the Microsoft.Dexterity.Applications.Dynamics.Globals.IsWebClient application global variable, which could be better performing than repeated calls to the function. This variable is set when a user logs into the system or switches companies. Great post! MG.- Mariano Gomez, MVP