Open Forum

Expand all | Collapse all

VST vs Plain Visual Studio

  • 1.  VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 16, 2017 12:09 PM
    I meant to ask this question in the developers round table, but of course it slipped my mind. I've always done my .NET AddIns in just plain old Visual Studio with the appropriate project references (Dynamics, Application.Dynamics, etc.).

    So am I missing out on anything by not using VST? I've never noticed any issues, but am curious if there is some killer feature in VST that I'm not taking advantage of.

    ------------------------------
    Matthew Arp
    Business Systems Developer
    Hunton Group
    Houston TX
    ------------------------------
    Conference-GPUG_200x200


  • 2.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 16, 2017 12:14 PM
    ​It is always safer to interface with Great Plains in the recommended manner.
    One possible advantage is enhanced Intellisense that will actually generate some of the needed code.
    Whether you would gain any significant advantage is hard to say.

    ------------------------------
    Bruce Strom
    Programmer Analyst
    Associated Grocers of Florida
    sunrise FL
    ------------------------------

    Conference-GPUG_200x200


  • 3.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 16, 2017 03:35 PM
    The VST includes some dexterity style forms you can use in your projects.
    However, I have had problems with these in prior versions, and converted them to normal VS forms, but in the latest versions of VST they should be okay.

    ------------------------------
    Bruce Strom
    Programmer Analyst
    Associated Grocers of Florida
    sunrise FL
    ------------------------------

    Conference-GPUG_200x200


  • 4.  RE: VST vs Plain Visual Studio

    GPUG ALL STAR
    Posted Oct 17, 2017 12:46 AM
    Hi Matthew

    If you are going to integrate with Microsoft Dynamics GP, then why bother not using the supported method by using Visual Studio Tools for Microsoft Dynamics GP.

    You are just going to make life hard by trying to get vanilla Visual Studio to work with Dynamics GP.

    David

    ------------------------------
    David Musgrave MVP, GPUG All-Star

    Managing Director
    Winthrop Development Consultants

    Perth, Western Australia

    http://www.winthropdc.com
    ------------------------------

    Conference-GPUG_200x200


  • 5.  RE: VST vs Plain Visual Studio

    GPUG ALL STAR
    Posted Oct 17, 2017 02:44 AM
    In the days when there was no Visual Studio Tools, the only method available to integrate outside Visual Studio applications to Dynamics GP was by using the old fashioned Continuum COM automation library. Continuum assumes the developer has ample knowledge (interestingly enough) of Dexterity as some of the things afforded to Continuum are not even available with VST. For example, Continuum allows for the creation of Dexterity on-the-fly triggers and allows the execution of pass-through sanScript code.

    Visual Studio Tools however, allows you to take advantage of CLR and the .NET runtime, making all your code managed code. Because all your code is CLR compliant, you enjoy some powerful benefits available to .NET code, like garbage collection. In addition, a number of assemblies and templates have been provided to allow VST applications to behave and look very similar to Dexterity applications. To me, personally, this is the most important benefit. For example, not having to use ADO.NET (or any other data access method) to access tables is a huge advantage.

    Finally, using the VST application templates to build your UI (WinForms) allow your VST applications to be almost instantaneously web client compatible. You don't get this with standard .NET forms.

    Also, being a .NET developer, you are probably aware of the disadvantages of using COM in .NET -- it works, but...


    ------------------------------
    Mariano Gomez
    Software Development Manager
    Mekorma
    Roswell GA
    ------------------------------

    Conference-GPUG_200x200


  • 6.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 08:40 AM
    Thanks for all the feedback! I think I may have mis-worded my original question, is there any benefit to using the Visual Studio Tools for Microsoft Dynamics GP Add In. All of the development I'm is using the recommended .NET runtime integration points, but I am not using the actual Add In for Visual Studio. I am curious if there was any reason for (or not) using the actual Add In that you can install for Visual Studio.

    I've generally found that Add In was cumbersome simply because it is tied to a particular version of GP/Visual Studio, so if you want to develop say a GP2013 R2 integration, you have to use a specific version of Visual Studio (that is probably way out of date).

    ------------------------------
    Matthew Arp
    Business Systems Developer
    Hunton Group
    Houston TX
    ------------------------------

    Conference-GPUG_200x200


  • 7.  RE: VST vs Plain Visual Studio

    Posted Oct 17, 2017 08:46 AM
    Hi Matthew,

    I do not use the VS templates for GP add-ins. You may also just simply add references to Windows forms to your Add-in project, and build the project manually. If I have a project that is UI heavy, I will build the UI out in Dexterity, build the chunk file, and run the library in the assembly generator to create a DLL for my .Net add-in. This way, I can keep the UI elements exactly as they look in GP.

    Here is an article I wrote to build a project template. Getting Started with GP AddIns using Visual Studio
    Gpug remove preview
    Getting Started with GP AddIns using Visual Studio
    Clicking OK creates a default project containing the GpAddIn.cs file, a resource folder filled with GP icons, and references to the Dynamics Dexterity bridges needed to interpret the addin. This file is the kick-off GP uses to consume the addin, and the output of this file is a dynamic linked library.
    View this on Gpug >


    ------------------------------
    Joshua Pelkola
    Managing Consultant
    BKD Technologies
    San Antonio TX
    ------------------------------

    Conference-GPUG_200x200


  • 8.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 11:05 AM
    @Joshua Pelkola, thanks for the info! Building the UI in Dex sounds super interesting. I've always hated the performance penalty that gets introduced when​ using .NET Forms in GP (which might be all in my head). I actually have my own blog post too about enhancing the .NET AddIn loading process *insert shameless plug*

    Matthew Arp's Blog - GPUG - Dynamics GP User Group
    Gpug remove preview
    Matthew Arp's Blog - GPUG - Dynamics GP User Group
    Lists all of the the blog entries
    View this on Gpug >
    https://www.gpug.com/blogs/matthew-arp/2017/03/30/gp-addin-enhanced-hurdle-1



    ------------------------------
    Matthew Arp
    Business Systems Developer
    Hunton Group
    Houston TX
    ------------------------------

    Conference-GPUG_200x200


  • 9.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 09:10 AM
    WOW, this is good, I am just a bear of very little brain, but we have the two wisest WOL's to answer all our questions, and I have a few minor questions myself.

    I have been developing for Great Plains since the DOS days, and the biggest lesson I have learned is your life will be much easier if you follow the Great Plains recommendations as close as you can, unless you have a REALLY good reason to go counter to them.

    What I do is have a separate set of .NET code for each major version of Dynamics.  We converted to GP2013 quite late, and by the time we did I had to upgrade my Visual Studio, and was not able to upgrade to VS2012, but rather to VS2013, which GP2013 does not formally support.  Everything is working, except that the Intellisense to generate new functions did not quite work.  I presume that Intellisense will work again with GP2016, since it supports VS2013.  (Our company will upgrade GP and VS real soon now.)  So I think the Intellisense is one major reason to upgrade.

    If you wanted to, and you did not care about Intellisense, you could probably get  away with having a set of code for all versions of Dynamics compiled under the exact same .NET framework, so you can match the .NET framework your .NET code is pointing to.  Personally, I think this is an unnecessary risk.

    Question: Is it necessary to have a set of VS code for each SP of Dynamics?  (I don't think so, personally.)

    You would probably want to segregate code with long computations that does not need to refer to any Dynamics resources into it's own class/DLL to cut down on the duplicated code, which is just good practice anyway.


    ------------------------------
    Bruce Strom
    Programmer Analyst
    Associated Grocers of Florida
    sunrise FL
    ------------------------------

    Conference-GPUG_200x200


  • 10.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 09:22 AM
    Now for my VS Studio Tools question:

    We are assuming we upgrade to the new version of VS Tools for each major version of Dynamics GP.

    Included with the VS Tools are these files that integrate your .NET code with Dynamics:
    Application.<DynamicsModule>.dll
    Application.<DynamicsModule>.xml
    Microsoft.Dynamics.<whatever>.dll
    Microsoft.Dexterity.<whatever>.dll

    When Great Plains releases a new service pack, should we copy the updated Microsoft.Dynamics.<whatever>.dll and Microsoft.Dexterity.<whatever>.dll files into the GP2016 VS Tools SDK subdirectory?

    When Great Plains releases a new service pack, should we copy the updated Application.<DynamicsModule>.dll files into the GP2016 VS Tools SDK subdirectory?

    If YES is the answer to the second question, what about the Application.<DynamicsModule>.xml files?  These are not in the Dynamics program folder.  Are they available from GP if we ask for them?

    ------------------------------
    Bruce Strom
    Programmer Analyst
    Associated Grocers of Florida
    sunrise FL
    ------------------------------

    Conference-GPUG_200x200


  • 11.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 10:58 AM
    So here's my two cents on your last post Bruce. When I'm compiling, I just reference the dll files that are in GP's directory not the SDK. I have a local client installed, and this way whatever version of the dlls come with the client, I can be sure those are the versions I reference in my code. I have run into situations where my code would reference a certain version of a DAG'd modified forms dll, and some integration we have would be expecting another version. So it can be a real bear if you start trying to manage dlls, that's why I just reference the ones directly in the GP directory. :)

    ------------------------------
    Matthew Arp
    Business Systems Developer
    Hunton Group
    Houston TX
    ------------------------------

    Conference-GPUG_200x200


  • 12.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 10:52 AM
    So, having different sets of code for each version of GP is not required. As long as your code will compile with the correct dll references (which ARE GP version specific) then your library is good to be tested/deployed.

    Now, with that said, one thing I would recommend. In the newer versions of Visual Studio they have baked in version control (git). If you are using this I would highly recommend creating a new branch for each GP version that you compile against. This way you would have all of your previous versions and they'd be separated by GP version if you had to make any version specific adjustments. This would probably be over kill for most people but I imagine it is one of those things that can really save your skin in those rare circumstances.

    ------------------------------
    Matthew Arp
    Business Systems Developer
    Hunton Group
    Houston TX
    ------------------------------

    Conference-GPUG_200x200


  • 13.  RE: VST vs Plain Visual Studio

    TOP CONTRIBUTOR
    Posted Oct 17, 2017 11:25 AM
    Having separate .NET code bases for each version of GP does not hurt, and is safer, and if I ever run into some funky problem nobody can resolve I will do that anyway to try to solve the problem, so I just think that is the safest option.

    I am thinking that once you place the compiled .NET code into the AddIn subdirectory it will be referencing the Dynamics versions of the DLL's anyway, so the question should be non-consequential, unless the signature of any of the classes change, which shouldn't happen to black boxes, but that is something I have no control over.

    But I am curious what Mariano and David think, as this is as much a question of practical experience as it is a theoretical question.

    My strategy is to use Dexterity whenever possible, and use .NET to interface with Crystal Reports, as this is the preferred direction of our company, and use .NET to do anything that Dexterity cannot do, like sensing the value of environment variables and reading the file names in a particular directory.  A separate thread in this forum and a GP support case indicates that using .NET to do sophisticated programming with scrolling windows is very problematic, and if it is possible, as I suspect it is, it requires some secret knowledge that I just do not have and cannot find.

    ------------------------------
    Bruce Strom
    Programmer Analyst
    Associated Grocers of Florida
    sunrise FL
    ------------------------------

    Conference-GPUG_200x200


  • 14.  RE: VST vs Plain Visual Studio

    GPUG ALL STAR
    Posted Oct 17, 2017 10:20 PM
    Guys,

    We have always said that whatever works for you, that's the solution and not that you need to follow some conventional method of getting things done. With that said, I am a big source control advocate, so the same code written for one version of GP can quickly be recompiled for another version. I do this all the time, even for Visual Studio Tools code.

    On another note, I have always liked the ability to develop the UI in Dex and drive the automation of the UI from Visual Studio (Tools or otherwise). I like the simplicity of this approach. I also like developing all tables in Dex and expose those to Visual Studio as well. Visual Studio Tools allows you to access Dex tables without needing ADO and perform table range operations as well.

    Bottom line is, whatever works for you, that's what you should go with.

    ------------------------------
    Mariano Gomez, MVP, Dynamics Credentialed Professional
    Software Development Manager
    Mekorma
    Alpharetta GA
    ------------------------------

    Conference-GPUG_200x200


If you've found this thread useful, dive deeper into User Group community content by role