Jeremy Tammik blogging on the Revit API

December 15, 2010

VSTA to Stay and Updater to Go

As you may have heard from Kean, we have safely
arrived in Munich, Germany for
the next developer conference, the biggest one in our European series.
Actually, he only talks about his own arrival, but our arrival worked all right as well.

One topic that we are discussing at these conferences is cloud computing, so it was a funny coincidence to run into a nice big tangible cloud when we went out to have a dinner with our developer partners in
Heaven 23
in Gothenburg before departing for Munich:

As you can see, the cloud can be accessed through reflection as well as the web service :-)

Meanwhile, here are some questions that cropped up several times at
Autodesk University and
were mentioned during some of our meetings here in Europe as well:

Can we rely on VSTA remaining? We heard that VBA for AutoCAD went away; is there any risk of that happening with VSTA for Revit as well?

Can I use the Dynamic Model Update technology if I wish to distribute a model to customers without my add-in? A warning message is displayed. This is incomprehensible and worrying for the uninitiated user. How can I handle this gracefully, and best of all suppress it completely?

VSTA to Stay

VSTA is an acronym for Visual Studio Tools for Applications.
It is included in every Revit installation, so every user has access to it.
It provides an IDE or Integrated Development Environment for exploring the API and creating macros.
The code is almost completely compatible with the .NET API we use for external commands and applications defined in standard add-ins.

Macros written in VSTA can easily be moved to an external add-in, and vice versa.

One advantage of VSTA is the ability to edit and continue, which is currently not supported by the Visual Studio environment when creating standard external add-ins.

Some developers and users have been careful about jumping onto VSTA, because it is a Microsoft product, analogous to the old VBA, Visual Basic for Applications.
VBA has been around for quite a while and was included in AutoCAD.
It is now being phased out, since Microsoft is reducing support for it.

As said, VSTA is here to stay.
Here is a statement on this by Anthony Hauck, Revit Design Product Line Manager:

Autodesk is happy to announce an agreement with Microsoft to include the Visual Studio Tools for Applications (VSTA) development environment in all Revit products for the foreseeable future.
Previous communications touching on the status of VSTA in Revit expressed some uncertainty as to its inclusion with future versions, but with the agreement concluded earlier this year we are pleased that VSTA will continue to be an important development option for users of the Revit API.

However, when a Revit model is modified by an updater and then distributed to a client without the add-in installed, a warning message is displayed which is not comprehensible for an uninitiated user.

For example, I implemented a minimal DMU application and ran the updater in a model, saved it, and reopen it later without the add-in defining the updater loaded.
The following message appeared:

For completeness' sake, here is the
DummyUpdater
application that I used to cause this message to appear.

How can I remove the reference to this updater from the model, in order to distribute it to a customer with no access to my add-in?

The very simplest answer is to tell you user to click on 'Do not warn about this updater again and continue working with the file', save the model, and continue working with it as normal.

However, many developers would prefer this message not to appear at all.

To achieve this, simply click on 'Do not warn about this updater again and continue working with the file' and save the model yourself and then pass it on to the customer.

The next time it is opened, the warning will no longer appear, because the reference to the updater has been removed.

Obviously, you need to well understand the consequences of removing this reference, and your application needs to be prepared to handle the situation in case it is ever loaded into the model again at a later stage, when changes may have been applied in its absence.

Automating Updater Removal

If you downloaded my sample DMU application above, you may have noted an empty add-in skeleton in it named RemoveUpdater.
I was originally planning to implement an add-in which automates the process of opening a Revit model containing an updater reference to remove, clicking on the option mentioned above, and saving and closing the file.

When I looked at this a bit more closely, I thought that I could save myself some work by creating a journal file to do the job instead.
It works really well.
I did the following: