EA Installation Issues

This page:

• Outlines basic installation requirements for EA AddIn
• Some common EA AddIn installation Issues

Preamble

As a background it is useful to note that any application, such as EA, can dynamically load a class library (DLL) to use those public classes that are provided by that library. The application would know the required class and method(s) it wants to use. In the case of EA the automation interface class is defined in the "Sparx" area of the registry for each AddIn. During initialisation EA looks for AddIns and can then, using information in the registry can load the DLL and invoke the required method.

Example

Below is an outline of code, specifically for a test AddIn called EAFeaturesTester. The EA Automation interface is in the class EA_Interface, and the test method testFunction has no parameters, it simply returns a string value. The code:

• Looks for the class information in the registry to get the filename
• Load the DLL file
• Get the type of the assembly
• Get the required method information
• Create an instance of the class
• Invoke the method (in our case with a method that has no parameters) and get the result

Dim _key As String = "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\EAFeaturesTester.EA_Interface\CLSID"
Dim _CLSID As String = Registry.GetValue(_key, "", "NotFound")
Dim _location As String = "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\" &  _CLSID & "\InprocServer32"
Dim _Filename As String = Registry.GetValue(_location, "CodeBase", "NotSet")
If Strings.Left(_Filename, 8) = "file:///" Then _Filename = Strings.Right(_Filename, _Filename.Length - 8)
Dim asm = Assembly.LoadFile(_Filename)
Dim t As Type = asm.GetType("EAFeaturesTester.EA_Interface")
Dim methodInfo = t.GetMethod("testFunction")
Dim classinstance = Activator.CreateInstance(t)
Dim result = methodInfo.Invoke(classinstance, nothing)

Requirements

To be able to load an AddIn the following must be in place

Let EA know about your addin.

Upon load EA read the information for addins from the registry. To be known to EA the addin must provide a subkey within a 'Sparx Systems\EAAddin key. Depending on your environment and deployment requirement there may be several possible Sparx Keys as follows:

• Deployed on a 64-bit system for current user only - in this case the key will be located under \HKEY_CURRENT_USER\Software\Sparx Systems\EAAddins\
• Deployed on a 64-bit system for all users - in this case the key will be located under \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sparx Systems\EAAddins
• Deployed on a 32-bit system for all users - in this case the key will be located under \HKEY_LOCAL_MACHINE\SOFTWARE\Sparx Systems\EAAddins

The name of the addin key is used as the description of the AddIn. The default addin key value is the name of the class that EA will load.

Example

Keyname: HKEY_CURRENT_USER\Software\Sparx Systems\EAAddins\EA Features Tester - my name

Default value: EAFeaturesTester.EA_Interface

The Addin class must be registered

EA attempts to load the AddIn class e.g.class library (DLL) containing your AddIn interface code. To find the DLL the must be registered (for example using RegAsm or as part of the installer).

This will result in the creation of an entry in the registry for ALL public class methods defined in the AddIn DLL. (Note: when creating an AddIn DLL ensure you set the scope of your methods to limit those that need to be exposed!)

Once again there are several locations where the class may be registered.

• HKEY_CURRENT_USER\Software\Classes
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes

A further key will be added to HKEY_CLASSES_ROOT - which is the value that will be used during load. Hence, if the AddIn has been registered for both HKLM and HKCU then the entry in HKCR will reflect that defined by the current user (HKCU).

Example

• Using batch/cmd file with the following contents to register our example AddIn (for current user) - "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "./bin/Debug/EAFeaturesTester.dll" /codebase

When run (noting that it must be run from a location that is consistent with the specified DLL filename path).

• An entry is created for the addin as follows - HKEY_CLASSES_ROOT\EAFeaturesTester.EA_Interface
• This entry has a subkey - HKEY_CLASSES_ROOT\EAFeaturesTester.EA_Interface\CLSID - which defines the Class ID (a GUID) created (by the system) during registration.

The Addin class DLL must be in the location defined in the class key

The CLSID entry for the AddIn has a GUID which is a reference to an entry in HKEY_CLASSES_ROOT\Wow6432Node\CLSID and HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID or HKEY_CLASSES_ROOT\Wow6432Node\CLSID and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID

NOTE:

• EA is a 32-bit app hence the location of keys under Wow6432Node.
• The class entry that will be used should be that referenced under HKEY_CLASSES_ROOT\Wow6432Node\CLSID

Within that entry there is a subkey which provides the full filename of the DLL.

Example

Example Addin has key

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{90E7AEBF-3CE4-3A58-9A07-CE605DAC6312}

with subkey

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{90E7AEBF-3CE4-3A58-9A07-CE605DAC6312}\InprocServer32

And in screen shot below the reference to the DLL (codebase) can be seen.

Attach:AddInClassFilename.png Δ

FAQ

In this section I try and collect information about issues I have seen relating to EA AddIns.

My AddIn isn't listed in EA

This means that EA could find a key defining your AddIn. A key for your AddIn must exist within the Sparx EAAddins key which provides the AddIn name and the class that includes the required EA API Add-In methods, also see Let EA know about my AddIn

AddIn not enabled and “error – Missing 0x80040154” in the Sparx Add-in Manager window.

From the windows error codes reference this error number indicates "80040154 2147746132 REGDB_E_CLASSNOTREG: Class not registered" and hence the AddIn DLL cannot be found. This could be due to:

• The DLL has not be registered correctly

or

• The DLL file doesn't exist at the registered location

Using the EAInstallation Inspector the relevant AddIn entry can be inspected.

• If there is no DLL filename listed then implies the class is not registered.
• If the DLL filename is listed then it implies it has been registered OK, so check the specified location to verify an EXACT match on the DLL filename.

NB: Also to Local Admin rights are required to register a DLL for All Users (i.e. Local machine)

Not running the correct version of AddIn - DLL confusion

It is possible that an AddIn may be installed for All Users (Local machine) and for the current user at the same time. And although, in principle, this should work I have seen instances where this has not been the case for those developing and trying to debug an AddIn, so probably only an issue for AddIn developers debugging code.

To check:

• Select the registry tree view
• Select the classname entry for the required AddIn
• Use the context menu and initiate a search for the classname.

2 searches are performed one for each of the areas HKLM and HKCU. If the AddIn interface class exists in both areas then this indicates the AddIn has been installed for Local Machine and Current User. As I said this should not normally be an issue as the HKEY_CLASSES_ROOT view should point to the correct version.

Now as I understand it if there is a local machine installation of an Addin, then this will execute unless there is a Current User instance, which will have precedence. What I have witnessed are cases where this has not happened. It could be that the registration of the class for the Current User didn't work (whatever completely working would be) and that the issue become apparent when debugging as the source file didn't match the file as indicated in the Inspector and also functions such as Edit & Continue failed.

So if you get some strangeness like this ensure that there are not multiple versions of your AddIn installed - and if so may be prudent to remove all, check with the Inspector and register the class that you want to debug.

Addin missing after .NET security update

I saw this on the Sparx Forum COM component (addin) "missing" due to .NET update - although I haven't seen this I am glad that it was posted as it could be useful to others.

Check list

The following are required to ensure that an EA addin is available:

• The AddIn must be built as a windows class library (DLL) with a public class known (defined by the user) that exposes class methods defined by the Sparx EA Addin model
• The AddIn must be assigned a key within one of the Sparx Systems EAAddIns registry areas within HKCU or HKLM
• The AddIn key entry must have a name with a value that represents the class containing the public (EA compliant) methods provided by the AddIn
• The class library must be registered, so that there is an entry for each public method defined in the library (NOTE: you may want to minimise public classes to avoid a glut of entries)
• When debugging you may need to add or modify the EA.exe.config file located in the EA.exe install directory.