VBA and VB6 with ArcGIS: What's the Story?

Coming out of the ESRI Developer Summit last week, and hearing some buzz about this on Twitter, we figured it would be a good time to catch everyone up with the ArcGIS support story for Visual Basic 6 (VB6) and Visual Basic for Applications (VBA).  We wrote a few notes on this a while back, but here’s the scoop.

Visual Basic 6 Support

This development environment is fully tested, documented, and supported for use with ArcGIS through version 9.3.1.  

The v9.3.1 release will include a version of the VB6 Software Developer Kit (SDK) for both ArcGIS Desktop and ArcGIS Engine.  For the past few years Microsoft has been phasing out support for VB6, finally considering it unsupported as of 2008.  Due to this, ESRI will not be releasing a VB6 SDK, nor supporting VB6 at the ArcGIS 10 release.  We continue to encourage users and developers to migrate their projects and code to more recent versions of Microsoft Visual Studio which use the .NET Framework.

What about your existing VB6 code?  Well on the one hand, your code may just continue to work with version 10, but one should not count on that for planning purposes.  In addition, VB6 documentation, samples, and other resources for earlier versions of ArcGIS will still be searchable online.  As for the user community, VB6 users will probably be there for some time into the future, but you should probably expect that the size of this group will continue getting smaller.  On the other hand (and more importantly) you will not have an SDK for VB6 at version 10 nor will technical support services from ESRI or our distributors be available, so our ability to support what you are doing will be significantly limited.

Another point worth mentioning is that ArcGIS will no longer install the Microsoft VB6 runtime at v10.  This is something to consider if you plan to deploy VB6 solutions to machines on which v10 is installed.

Check out this migration post to see how to use the Visual Studio Update Wizard to convert your code.

So to summarize:

For ArcGIS through v9.3.1:  VB6 is fully supported.
For ArcGIS 10:  VB6 will be unsupported.  Your code may just work, but there will be no VB6 SDK, nor technical support services. 

VBA Support

For about 12 years now since version 8.0, ArcGIS Desktop users have been able to take advantage of the embedded VBA Editor to write macros, code modules, etc.  The status of VBA going forward is this.  VBA is fully supported through ArcGIS Desktop version 9.3.1, however developers are encouraged to use supported versions of Microsoft Visual Studio when extending the ArcGIS Desktop applications.  When ArcGIS 10 is released, VBA will no longer be recommended for use, however it will still be available in order to support legacy code and applications.

So to summarize:

For ArcGIS Desktop through v9.3.1:  VBA is included and fully supported.
For ArcGIS Desktop 10:  VBA will be available if needed, fully supported but not recommended.

(edited on 6.28.2010 to replace “v9.4″ with “v10″ due to version renumbering)

This entry was posted in Developer and tagged , , , . Bookmark the permalink.

Leave a Reply


  1. alaframboise says:

    Sorry for the delay folks.

    Scott: As with all releases, we are working hard to maintain all aspects of backwards compatibility with the 9.4 release. Features such as VB scripting will still be supported but we will be considering alternative methods to scripting as we move forward.

    Simon: As technology evolves, we evolve as well. When a development environment is no longer supported by a vendor, it makes it very difficult for us to build and design future versions of our software on those technologies.

    And to your second point, there are definitely advantages and disadvantages to writing code in the application tier vs in DLLs. One thing to keep in mind however is that writing pure .NET DLLs is considerably easier than writing and deploying traditional COM DLLs. DLLs also make it easier to separate tiers of business logic so that code can be reused across many different applications. That said, we also recognize the benefits of writing code within the application framework itself, and are taking this into serious consideration for the future releases.

    EDN Team

  2. Hornbydd says:

    I’ve been developing ArcObjects solutions for clients and projects since ArcGIS 8.1.

    Usually this is in VB6/VBA and more recently I’m starting to get to grips with VB .Net. I personally find python too slow and does not offer the rich toolkit of objects that ArcObjects has.

    You might as well put a gun to my head and pull the trigger if you remove the ability to write code within a MXD! I do most of my coding within the VBA editor because its fast prototyping environment. For example, if one of my colleagues needs a solution that the geo-processing tools are unable to achieve then I usually knock out some quick code in an MXD. Some of my biggest and most successful projects have all run within a single MXD!

    As a developer I understand its considered more clever doing it in visual studio but as a consultant who has to deal with clients and colleagues with differing skill levels, resources, time and money the MXD is often the only way to deliver.

    Consider this…

    I had to work for a client to process a significant amount of data as well as providing a tool for them to use at the end of the project. Despite them calling the shots, their own IT department would not allow DLLs… So how can I do the “clever” thing and develop an extension, the answer was an mxd!

    Please don’t take away the ability to write custom code, forms and toolbars from a MXD.

    • arisrinke says:

      You can keep scripting in an MXD with the ARIS .Net Scripting Tool for ArcMap (http://www.aris.nl/dotnetscripting_arcmap)
      With this tool you can create, edit and run DotNet code within an ArcMap session, without the need for Visual Studio.
      It is a good replacement for VBA to store code in your project, but it is also a good prototyping tool to test VB.Net code before it is being used in a DLL.

  3. stevel says:

    When you’re looking at upgrading VB Script, could you please focus on building in some error checking? “User Interrupt” doesn’t help when trying to debug a complex VB Script labelling expression.


  4. pierre.k says:

    What about VSTA? Does ESRI plan to support this platform in the future?

  5. kirkktx says:

    It seems to me that ESRI could replace the VBA IDE with something like the ActivePro syntax editor control, and continue to support storing code in the mxd.  http://www.actiprosoftware.com/Products/DotNet/WindowsForms/SyntaxEditor/default.aspx .

    Linqpad uses this.  I think it would be great to have something like linqpad to test out arcobjects snippets.  

  6. alexbrew22 says:

    I am not a developer nor a programmer, but I have hired hard working guys to write VBA scripts to assist our surveyors and engineers with many “add-ons” to ArcGIS. Most of these guys have moved on (literally) to other places and locations.

    It is not a good feeling to know that 10.0 will not support VBA. I hear there may be a code to unlock this ability. Will there be a huge price tag? We certainly have purchased our share of licenses in the last decade. Concerned to say the least.

  7. jbarry says:

    >It is not a good feeling to know that 10.0 will not support VBA

    ArcGIS Desktop v10 will continue to support VBA. It is a separate license and install, but no extra cost. That said, VBA is not planned to be supported in versions after 10.

  8. jjr@therogers.com.au says:

    We have been told by ESRI Australia that VBA will not work in 10.1. Is that correct?

  9. avanderschrier says:

    The link to “Check out this migration post to see how to use the Visual Studio Update Wizard to convert your code” is broken. Can you please supply the new link so we can learn more about how to convert VBA code?