Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: yellowface on April 17, 2008, 05:10:36 am
-
Hello every1:
I have a wired problem with regasm.exe right now. Here is the situation:
I am developing an EA Add-In right now. When I select output type as Class Library, also I checked the Register for COM Interop(in this case, I do not need to run regasm add-in.dll for registering), EA can successfully load my add-in without any problems. I tried regasm add-in.dll /unregister and opened EA, the add-in is not there for sure(regasm /unregister works in this case)
However, if i did not check the register for COM Interop when I do the output with Class Library and using regasm to register my add-in(it shows successfully register), but EA cannot load my Add-IN, showing Error-Missing.
Any1 has any ideas what is wrong with that? I have .Net SDK installed and develop environment is VS.2003.
Thank you very much if any1 here can help me.
-
It's about Visual Studio .Net I suppose.
Maybe when you don't check "Register for COM Interop" VS doesn't create the type library, i.e. your dll with its public class can be registered by regasm, but VS does not create GUIDs and stuff for the public functions, so EA will not find the entry points it needs.
-
And make sure you tell .Net to make the appropriate classes, methods etc. COM-visible, or you still won't see them in the compiled file (and nor will COM).
You'll need to add some .Net attributes to your assembly, classes, methods, properties, etc. The .Net documentation covers this in detail. When you set up a project by hand these are done for you. I'm not sure if changing it later works, but I think you can do it (at least with VS 2005 and later).
Failing to do this is a common error when retrofitting a project by hand for COM visibility.
David
-
i found solution. guess what? lol
i should do regasm name.dll /codebase, then the lib got registered.
if i do regasm name.dll never works. grrr....
-
Excellent!
Or so it appears. Just to confirm, did this solve the entire problem?
We're seeing a problem reported elsewhere that might have some common elements.
David
-
This didn't solve the problem.
I am developing an EA Add-In right now. When I select output type as Class Library, also I checked the Register for COM Interop(in this case, I do not need to run regasm add-in.dll for registering), EA can successfully load my add-in without any problems.
In this case also EA is not loading the addin and my addin doesn't display. I also tried by registering using regasm add-in.dll /register
add-in.dll /codebase, it's not working.
I feel this is not a solution for the problem.
-
Yellowface / Vibhu,
A couple of thoughts:
1) Can you confirm that you are referencing Interop.EA.dll in your .NET Add-In projects and not EA.TLB? For .NET projects, it is important to reference via the Interop and not the typelib.
2) Where are you deploying your Add-In dll? Sometimes for best results you might consider installing the DLL within the some folder where EA is installed.
-
Aaron!
1)I tried referencing Interop.EA.dll from EA trial installation folder bot it was giving error so I read on the same forum and add EA.tlb as reference and it started working.
2) Doesn't metter where to deploy addin dll. I have tried all that but it didn't work.
Vibhu
-
Yellowface / Vibhu,
A couple of thoughts:
1) Can you confirm that you are referencing Interop.EA.dll in your .NET Add-In projects and not EA.TLB? For .NET projects, it is important to reference via the Interop and not the typelib.
2) Where are you deploying your Add-In dll? Sometimes for best results you might consider installing the DLL within the some folder where EA is installed.
Just wondering aloud...
Perhaps the version of .Net that the (Sparx version of the) Interop was built against is posing an upward compatibility problem for those still developing against .Net 1.x.
If so, might this problem be solved by creating another Interop assembly using .Net 1.1 (for example), which these developers could link against?
This might pose problems of its own though. First, I don't know if it is even possible, or practical. Second, there might be issues with the assembly cache - global or otherwise. In the latter case these might not show up until an end user installed enough add-ins that both Interop assemblies were in play. Perhaps the issues wouldn't even show up until both versions were loaded by EA at run-time...
David
-
One more shot in the dark:
If you have an AddIn created with Visual Studio 2003 (i.e. Net 1.1) and a machine on which it is registered but doesn't show, you can force EA to load it with .Net Framework 1.1 (even if .Net Framework 2.0 is installed as well) by placing a file "EA.exe.config" in the EA program folder. The file has to contain this text:
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322"/>
</startup>
</configuration>
-
Thanks Frank!
That sounds like just the key.
-
Dear Frank / David!
I followed Frank's suggestion but it didn't work.
As per David when I tried new addin by adding the reference to Interop.EA.dll (EA 7.1 trial) it was giving error then I tried by adding the reference to EA.tlb. It added and my addin displayed on my machine. When I tried the same addin on two other machines it displayed on one and didn't on other machine.
This is a strange problem. I am not getting what the issue is ??
Please suggest me what to do to avoid this problem
-
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:
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:
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:
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"
-
Dear Frank / David!
I followed Frank's suggestion but it didn't work.
As per David when I tried new addin by adding the reference to Interop.EA.dll (EA 7.1 trial) it was giving error then I tried by adding the reference to EA.tlb. It added and my addin displayed on my machine. When I tried the same addin on two other machines it displayed on one and didn't on other machine.
This is a strange problem. I am not getting what the issue is ??
Please suggest me what to do to avoid this problem
Long shot here...
This is one of the really obvious questions - along the lines of "is the computer plugged in?" - but still worth asking.
Can you confirm that all your machines have the .Net 1.1 runtime installed? Perhaps they have only .Net 2.0, or that plus .Net 1.0.
Also, if they do have .Net 1.1 installed, insure that the service packs for .Net are also current.
David
-
David!
This is really obvious questions - along the lines of "is the computer plugged in?" - but still worth asking.
my machines have the .Net 1.1 runtime installed. Also the service pack of .net 1.1 are current.
I have installed the .net runtime on all the machines from the same setup file. On some machines addin is displaying and on another it's not displaying.
-
I got the solution for this. If addin doesn't display install .net framework 2.0 on your machine and your addin will display.
-
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.
-
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
-
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:
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:
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:
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"
-
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
-
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.
-
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
-
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?
-
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
-
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
-
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
-
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)
-
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 :)
-
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.
-
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
-
But that's not the "COM way".