COM Calling DotNet

  • Thread starter Thread starter Derek Hart
  • Start date Start date
D

Derek Hart

I am unclear about what all the requirements are to call a simple vb.net
application, installed in the GAC, from COM (such as writing vba in Word to
call the dotnet dll).

I believe I have installed the dll in the GAC. It is in there and has a
public token. I did not create a key-value pair. I believe it is strong
named, as it shows up in the GAC.

How do I browse the objects of it? I would like to call it late bound, but
the errors I get show that the properties or methods are not available.

I have put <ComClass()> as an attribute at the beginning of the public
class.

In VS 2008, I have chosen Register to COM interop.

I have all the options in Wise Installbuilder showing that it installs the
assembly in the GAC.

I have made sure that the class has this code:
Public Sub New
MyBase.New
End Sub

Just how many guesses do we need to do to just call a dotnet object? Is
there an article that lists what is required, instead of just parts and
pieces.

Please help.
 
Also, I found this article:

http://msdn.microsoft.com/en-us/library/yf1d93sz(vs.71).aspx

In which it states:
In addition, it is not necessary to install assemblies into the global
assembly cache to make them accessible to COM interop or unmanaged code.

I sure wish I could figure out how to deploy a dotnet application, with has
a dll with public functions, and have COM objects use that, and not have to
use the GAC. But I need the code to be late bound in the COM programs
because I will not be able to set references to the DLLs or even know where
they are installed. Please point me in the right direction!
 
Hello Derek ,

All the steps that you describe ( make the assembly com visisble , create
a public sub new )
sounds how i create my .Net dll`s COM callable however i missed only one
thing you did not mention

Did you register the COM capable assembly with regasm.exe ?


My dll`s are callable with CreateObject from VBA ,VBS and even PHP , with
PHP however i discovered that the assembly needed to be deployed in the GAC
or the APACHE assembly directory


here is some copy paste code i created a long time ago for this group

http://groups.google.com/group/micr...l+posseth+COM+VB.Net&rnum=28#ca996d74d250974e

As you see i create my own interface id`s , as this gives me the benefit of
compatibility through my rules


HTH

Michel Posseth
http://www.vbdotnetcoder.com
 
If I could get more specific, I would appreciate your thoughts. Please let
me know if my steps are wrong, or I am missing some, or if I don't need
some.



1) This is all I have done to strong name the vb.net dll. In the project
properties, under Signing, I have chosen Sign The Assembly and chosen New in
the combo box to make a new file. I simply named the file and gave it a
password. I did nothing in reference to the key value pair, as I do not need
this level of security. Is it required to make a key value pair, or is
simply naming this file enough? In my references, I see the name of my key
file. Should I set the build action to Embedded Resource, or is none the
right choice?

2) I don't want to install my DLL in the GAC. So please let me know if
that should be okay. Remember, I simply want to call the dll late bound from
vba, or other com programs.

3) I have made a public sub new in the main class I am calling with no
constructors.

4) My application compiles fine, as I made every dll "strong named",
using the rules stated above. No key value pairs were done. Just what I did
above.

5) I have the following at the top of my class:
<ComClass()> Public Class MyClass

6) I did not do any other code inside the class, using the GUIDs as you
showed in your explanation. I did not do ComVisible anywhere, just the
ComClass code.

7) I chose Register for Com Interop in the project properties, which is
probably why it works on my development machine.

8) I chose a similar option in Wise InstallBuilder when deploying, so it
should be doing regasm in the install.

9) My CreateObject on the deployed machine still gets ActiveX cannot
create object. It seems like I am going to have to go at this for a while.
Your feedback would be appreciated.



Thank You!
 
Hello Derek ,

About 1 and 2 , This is only necesary for the GAC i do not sign or strong
name my COM dll`s at all as i install them in the callers directory path ,
note that for a hosted runtime this must be the directory of the excution
host ( for PHP the apache assembly directory and for VBS the system32 dir )

The call places are , Callers instrallation directory , GAC and System32
so your dll must be in one of these locations

As the assembly behaves as expected on your development system ,(the VS IDE
is taking care of registering the COM assembly on the dev system )
this is where your focus should be .

I guess that Wise is not registering your .Net COM component the right way
, to confirm that this is the case do the following , open a command
window on a target system , go through the command prompt to the framework
directory ( normally this is "C:\Windows\Microsoft.Net\FrameworkNumber\"

If you have the blinking cursor on that location , type regasm
C:\FullpathTo\YourComDllName.dll and press enter you should get a
confirmation that it succeeded .

Now your assembly should work as expected , if it does ( i know that for
95% sure ) here is the solutions for your Wise project
on any system ( this may be your dev machine ) type now at the framework
command prompt :

regasm C:\FullpathTo\YourComDllName.dll /regfile:myRegistrationFile.reg

The registration file that is now created , should be included in your Wise
setup project
http://www.wisesolutions.com/upload/wfwi.pdf
see page 144 ( adding registry keys )
If you have done this , it should work for every installation you make with
your deploy package


I hope to hear from you if you succeeded (or not :-( )

Regards,

Michel Posseth
 
Hi Michael,

We register out .NET DLL's by installing them to the target location and
then using the following command:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm
<targetdir>\whatever.dll /codebase /s /tlb

This works for us. You did not mention the requirement to use /codebase when
registering the DLL. Isn't this required for DLL's which are not in the GAC?

This article says that it is required.

http://www.code-magazine.com/article.aspx?quickid=0703112&page=3
Developers should use the /codebase switch whenever they install the
assembly into a location other than the GAC. Basically, /codebase tells
Regasm.exe to include the path to the assembly in the registry so that the
COM client using it can find it. A quick look in the registry will reveal
that, in the CLSID key of the registered .NET assembly classes, Regasm added
a string value named CodeBase to the InprocServer32\ProductVersion subkeys.
This string value is the fully qualified path to the assembly that was
registered with the /codebase switch.

Maybe this will help the OP with his issue?

Hope this helps,

Joseph Geretz
 
Hello Joseph,

That is a good one , i guess that this is exactly what the OP needs as this
saves him form installing a copy of the Dll to the system32 or GAC to get it
to work in
third party applications that he is not aware of at the moment of
installation .

As far as i know the article you mention should tell it this way
Developers should use the /codebase switch whenever they install the
assembly into a location other than the GAC.
Click to expand...

my version :-)

Developers should use the /codebase switch whenever they install the
assembly into a location other than the callers assembly directory , the
systen32 directory or the GAC.

However AFAIK then it is also required to sign and strong name the assembly
, personally i just copy my dll to the callers directory


regards

Michel
 
Hi Michael,
my version :-)

Developers should use the /codebase switch whenever they install the
assembly into a location other than the callers assembly directory , the
systen32 directory or the GAC.
Click to expand...

Why, what is special about System32? I'm not a .NET expert, but I've been
working with COM/ActiveX for the past decade and there's nothing special
about the System32 folder in terms of COM DLL registration. Are you sure
that the /codebase parameter will not be required when installing a .NET DLL
to System32 and then registering for Interop?

Thanks,

Joseph Geretz
 
Back
Top