Book a Demo
Prev Next

Tips and Tricks




See also


The registration GUID and name used to register an Add-In should be the same for Enterprise Architect 32 bit and 64 bit versions. Only the name and/or location of the DLL should be different.

Enterprise Architect 64 bit and C++ Add-Ins

Apart from using the correct registration key (see step 4 in the Deploy Ad-Ins Help topic) there is no special configuration for getting a 64 bit COM object running under Enterprise Architect 64 bit.

Deploy Add-Ins

.NET Add-Ins

When generating a .NET assembly, you must explicitly set the 'Target Platform' to x86/x64.  Leaving it on 'Any CPU' could cause issues when Enterprise Architect 32 bit is run on a 64 bit version of windows.

Add a x64 Target to your project and rebuild the project.

Visual Studio has an issue when attempting to register a .NET assembly when the Interop.EA is included in a project.  It will attempt to use regasm for the architecture Interop.EA was built for. We have found adding to the Post-Build Script helps, if you uncheck the 'Register for COM interop' option in the project settings (assuming you have permission to write to the registry).

     if $(PlatformName) == x64 ( "%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)")

     if $(PlatformName) == x86 ( "%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)")

Note: At the time of writing, .NET Add-ins will not work under Wine and using Wine-Mono.

Java API

The Java API loads the last installed Enterprise Architect and isn't affected when using either the 32 or 64 version of the dll, as long as the SSJavaCOM DLL can be found by the Java runtime.

Visual Basic 5/6 Users Note

Visual Basic users should note that the version number of the Enterprise Architect interface is stored in the VBP project file in a form similar to this:

Reference=*\G{64FB2BF4-9EFA-11D2-8307-C45586000000}#2.2#0#..\..\..\..\Program Files\Sparx Systems\EA\EA.TLB#Enterprise Architect Object Model 2.02

If you experience problems moving from one version of Enterprise Architect to another, open the VBP file in a text editor and remove this line. Then open the project in Visual Basic and use Project-References to create a new reference to the Enterprise Architect Object model.

Holding State Information

It is possible for an Add-In to hold state information, meaning that data can be stored in member variables in response to one event and retrieved in another. There are some dangers in doing this:

  • Enterprise Architect Automation Objects do not update themselves in response to user activity, to activity on other workstations, or even to the actions of other objects in the same automation client; retaining handles to such objects between calls can result in the second event querying objects that have no relationship with the current state of Enterprise Architect
  • When you close Enterprise Architect, all Add-Ins are asked to shut down; if there are any external automation clients Enterprise Architect must stay active, in which case all the Add-Ins are reloaded, losing all the data
  • Enterprise Architect acting as an automation client does not close if an Add-In still holds a reference to it (releasing all references in the Disconnect() event avoids this problem)

It is recommended that unless there is a specific reason for doing so, the Add-In should use the repository parameter and its method and properties to provide the necessary data.

Enterprise Architect Not Closing

.NET Specific Issues

Automation checks the use of objects and will not allow any of them to be destroyed until they are no longer being used.

As noted in the Automation Interface topic, if your automation controller was written using the .NET framework, Enterprise Architect does not close even after you release all your references to it. To force the release of the COM pointers, call the memory management functions as shown:



Additionally, because automation clients hook into Enterprise Architect, which creates Add-Ins that in turn hook back into Enterprise Architect, it is possible to get into a deadlock situation where Enterprise Architect and the Add-Ins will not let go of one another and keep each other active. An Add-In might retain hooks into Enterprise Architect because:

  • It keeps a private reference to an Enterprise Architect object (see the earlier Holding State Information), or
  • It has been created by .NET and the GC mechanism has not yet released it

There are two actions required to avoid deadlock situations:

  • Automation controllers must call Repository.CloseAddins() at some point (perhaps at the end of processing)
  • Add-Ins must release all references to Enterprise Architect in the Disconnect() event; see the Add-In Events topic for details

It is possible that your Automation client controls a running instance of Enterprise Architect where the Add-Ins have not complied with the rules. In this case you could call Repository.Exit() to terminate Enterprise Architect.


In developing Add-Ins using the .NET framework you must select COM Interoperability in the project's properties in order for it to be recognized as an Add-In.

Some development environments do not automatically register COM DLLs on creation. You might have to do that manually before Enterprise Architect recognizes the Add-In.

You can use your private Add-In key (as required for Add-In deployment) to store configuration information pertinent to your Add-In.

Examples and Tips Tips and Tricks Add-In Events