Prompted by 2 queries in a week about missing Add-in DLL’s I thought a quick post of the subject may be useful.
One of the problems that I have seen many times during the development and use of EA extensions is the missing Add-In DLL.
If you look at the Manage EA Add-Ins window in EA you may see an entry, as listed in the screenshot below, in the status column indicating that something is missing.
There is a error code 8000401f3 which indicates that the application failed to create an instance of a COM object using a Class which is not registered on the machine. Hence EA is unable to load the AddIn.
Having seen this issue numerous times I developed my EA Installation Inspector. This program emulates the process that EA may perform in loading your Add-in (Caveat – I don’t have insight to how EA code or how it does stuff in detail works so it’s my guess but seems to work so far).
This program provides more information about the status of the AddIn as illustrated in the screenshot below.
In this screenshot the purple line indicates that the DLL has not been registered, and hence is unknown to windows. Read the documentation supplied with the AddIn for more information.
Two steps to installing an Add-In
To be able to use your Add-In (DLL/Class) it needs to be known by:
- EA as an Add-In
- Windows as a class that can be loaded
I’ll look at these in turn
How does EA know about your Add-In
EA knows about AddIns through registry keys located within the HKCU\Software\Sparx Systems\EAAddins… as illustrated in the screenshot below. The value associated with any of these keys needs to be accurate as it references the class defined in you DLL with the format Assembly.ClassName
This list of keys matches the list of AddIns shown in the manage Add-Ins window.
How does Windows know about your Add-In DLL
To be able to load your class EA will make calls to Windows, hence windows needs to know about your class as well, and your DLL (Class) must be registered with windows in a specific manner.
The registration of your class may be performed in different ways. Typically it can be done manually using Regasm or performed as part of your installation by your installer. The registration process should create keys in relevant places in the registry so that when a request is made to load your class the appropriate DLL can be found. There are different versions of RegAsm depending on which .NET framework is being used.
The EA manual indicates that the version of RegAsm to use is that provided with .Net 3.5 with the example
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe “C:\Program Files\MyCompany\EAAddin\EAAddin.dll” /codebase
I suspect, but not tested, that you should use the Regasm supplied with the framework you are using.
The problem as I see it is that with the co-existence of 32-bit and 64-bit programs the location of this information is crucial. Now I’m not a windows expert but I know that by working through the trail from the EA AddIn key,a slow process, a class can be registered with keys in the wrong place. So this is where EA Installation Inspector helps. It follows the trail through the registry from the EA AddIn key to finding the DLL file that contains the class that will be loaded.
So how to resolve
Typically when EA can’t find a file then keys have not been registered correctly. EA Installation Inspector will hopefully indicate the error condition and provide an indication of what is wrong e.g. DLL file missing, keys in wrong location.
To check I will usually then manually register the DLL and rerun the installation inspector to check if the situation has improved. So far this has usually worked and leads me to check out what settings are missing or incorrectly set either in the IDE I am using or in the installer definition.
Here are some checks that you can make which may help resolve your missing DLL within an IDE.
- Ensure that the DLL you are building is compatible with working with a 32-bit application. I always build my DLL’ 32-bit.
- With IDE’s check setting
- some of the defaults are geared towards 64-bit systems – e.g. default framework, default build configurations
- check the setting Register for COM interop
For installers it is usually the case of accurately checking the definitions – usually against a know good installer.
Hopefully this information has been useful in finding your Add-In. However, if not I’m always interested to know what other issues exists (and hopefully solve them), let me know