Regasm does not work

[vibhugupta]

I got the solution for this. If addin doesn't display install .net framework 2.0 on your machine and your addin will display.

[Frank Horn]

If addin doesn't display install .net framework 2.0 on your machine and your addin will display

Good to hear you've got it going.

Still I wonder why it should be necessary to install framework 2.0 to show an addin which has been compiled against framework 1.1. EA doesn't use .net framework, or does it? The addin mechanism is pure COM automation, so I think it must be possible to show the addin without framework 2.0.

[«Midnight»]

I suspect the add-in is the issue here.

I've said several times - in this thread and elsewhere; others have also said it - the software you use to create add-ins must be supported and correctly configured on the target machines. In the case of .Net this could imply everything up to service packs.

David

[jeanfrancois]

I am sorry to bring up an old thread. However, I searched the forum and read through most of the threads I can find with similar problem.

I also have Error-missing for my add-in when I try to install it on a different pc. I've tried it on one with 32bit and one 64bit. In both cases it does not work (I coded and debugged successfully on a 64bit similar to the one tested on). I get exact matches on my pc and the 32bit one as you have below.

I also register with regasm. It worked for another add-in of mine, but I cannot identify the differences, I literally used the same installer script with name changes only. I also succesfully see under HKEY_CLASSES_ROOT\Software\Sparx Systems\EAAddins my library.Main.

Any advice is welcome  

Vibhu,

can you compare the registry entries on the two machines (the one where your AddIn shows and the one where it doesn't)?
They should look like this (My AddIn is called "ITensiveEAFunctions" and has a public class "Main" implementing the required event handlers):

1. There must be a key with LibraryName.ClassName for EA to find the Guid of the COM object to create:

Code: [Select]

HKEY_CLASSES_ROOT\ITensiveEAFunctions.Main\CLSID

with a Guid value ({709BE3C9-91CE-3F20-A2E9-4B0298F873E7} in my case).

 2. For the Guid (ClassID) there must be an entry pointing to the code base:

Code: [Select]

HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}

with subkeys Implemented Categories, InprocServer32 and ProgID. The InprocServer32 key contains a value "RuntimeVersion" and a subkey for the current version, which again has a RuntimeVersion value.

Could you check if these keys are identical on both machines?

For comparison, here's the complete CLSID key for my AddIn:

Code: [Select]

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}]
@="ITensiveEAFunctions.Main"

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}\Implemented Categories]

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="ITensiveEAFunctions.Main"
"Assembly"="ITensiveEAFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///E:/NetProj2/ITensive/Development/ITensiveEAFunctions/bin/Debug/ITensiveEAFunctions.dll"

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}\InprocServer32\1.0.0.0]
"Class"="ITensiveEAFunctions.Main"
"Assembly"="ITensiveEAFunctions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///E:/NetProj2/ITensive/Development/ITensiveEAFunctions/bin/Debug/ITensiveEAFunctions.dll"

[HKEY_CLASSES_ROOT\CLSID\{709BE3C9-91CE-3F20-A2E9-4B0298F873E7}\ProgId]
@="ITensiveEAFunctions.Main"


[Geert Bellekens]

Jean-François

If the registration of your dll is working (and I assume it did since you haven't mentioned any errors about it) then EA is probably looking for the wrong thing.

You tell EA what to look for by the registry key in the EAAddins.

I remember having difficulties with it because there are several names you could put before the .main. Look into the help file to find out what exactly you need to put there. (was it the project name?)

If you are 100% sure that is ok then you could look at whether or not you have correctly told the dll it should be visible for COM.
There a bit of code that you need to add to the class (with a GUID) and some settings in Visual Studio to make sure the assembly is COM visible.

Geert

[jeanfrancois]

Hi Geert

I'm going mad by now, haha. I am pretty sure I'm doing something very stupid. The add-in works on all 64-bit systems (windows 7) though running as 32-bit in EA. However, it does not work on the 32-bit machine. The same registry key exists in EAAddins. And I register the dll successfully with regasm.

I did not use the project name with .Main (I used the assembly name), but changed my project name now to be same as namespace and assembly (i'm working on C# in visual studio btw). Still not working. I also registered the COMs in VS for the project, and it works fine for debugging as well as on the 64-bit machines.

The thing that troubles me is that I have another add-in that installs successfully on the 32-bit machine, and I do exactly the same for both.


The only difference between the two add-ins is that the one not working has the Main class as a derived class from a base class that implements the EA functions. However, I changed it now and removed base class like in the working add-in, but still it shows 'error-missing'.

I'm very confused why it doesn't work on the 32-bit machine. It even worked on the 64-bit machines when I didn't use the ProjectName.Main, but the assembly name.Main for EAAddins registry.

[Geert Bellekens]

Sorry Jean-François,

I'm all out of ideas now :-/

If I were you I would contact Sparx support and ask their help.
They are usually pretty responsive to concrete problems, but they are on the other side of the world, so count on at least one day before you get an answer

Geert

[philchudley]

Some extra throughts:

When developing under Visual Studio and using EA as the debug executable, the build of the solution will be Debug. All works fine, EA finds the Add-In

When re-building with the build of the solution of Release, EA (loaded outside Visual Studio) does not find the Add-In. The only solution I have found that works reliably is to copy the Add-In .dll to the installation folder of EA.exe. (As suggested by Aaron B)

Commercial Add-Ins seem to be able to place the .dll where they like, how do they do it?

[fwoolz]

Phil,

This (copying the .dll to the EA directory) is the approach I take since this appears to eliminate the "missing" dll issue. It would be interesting to find out how to get things working reliably regardless of where the dll is installed.

BTW, and totally off topic - does anyone besides me think that "regasm" is an... errrrrr, "unfortunate" name for a utility?

Fred

[Geert Bellekens]

I've recently created a couple of addins using VS 2008 (C#) and I have no problems with the location of the addin dll.
I've used the standard VS setup projects to install the addins.
The only thing you need to make sure is that it registers for COM interoperatebility.

I think in the background it uses regasm ("re", "or", whats the difference)
to registers the dll and its tbl file.

Now at home I'm trying to manually recreate the installation procedure that VS uses (VS Express doesn't support setup projects  ) I'll let you know when I've cracked it.

Geert

[Geert Bellekens]

After a bit of messing about, and then finally RTFM I found the trick.
You have to regasm the dll with the /codebase option
After doing that EA found myAddin.dll located in c:\program files\myAddin\

Geert

[jeanfrancois]

I do the same and use /codebase to add my addins to program files. I've made a small example plug-in once again successfully. I'm now going to keep adding stuff until it looks like the add-in with 'error-missing' until I see what causes it not to work. I'll let you know if I find out why.

(I've also tried copying the .dll into the EA folder but that hasn't worked with this add-in, and for the other working ones it's always worked with /codebase like Geert mentions)

[jeanfrancois]

Yes, was a stupid error. Since I was now deriving from a base class, this base class was new in another library, and an old version of this library was still in the EA folder, so by default EA used this old library instead of the newer library in my Program Files\Addin folder where my addin.dll was. I deleted the old library, and now it looks at the correct one in my addin folder.

Process Monitor showed this to me.

Thanks for help

[Frank Horn]

How can EA use an old library in it's installation folder? It should check the registry for the class name of the add in entry class, then for its guid, and then create a COM object by loading the library registered under this guid.

[Geert Bellekens]

I can image the standard procedure for such things is to first look into the working folder, and if not found there, check the registry.

Geert