(I am a novice with interop services so bear with me...)

I have a legacy C# application and am using VS2005 to generate a dll for it.
I want to make this available for COM access which requires, as I understand
it, invoking both gacutil and regasm. I am getting this error from regasm:

processing 'Ruby2net.IRuby2net, Ruby2net'. Error: Element not found.

I also tried tlbexp and received the same error.

Even though this error is present, I have been able to call the classes via
COM successfully. Until now, that is. My COM calls originate in a Ruby
application that had been working fine. I changed some of the
internals--nothing connected to the COM interface--and suddenly the ruby call

win32ole.new('Ruby2net.Ruby2netClass')

fails with "The system cannot find the file specified.".

So I am beginning to dig into this unfamiliar terrain. It seemed reasonable
to start with the regasm error since it seems vaguely related (to my
untrained eyes). I have been able to find a variety of sources on the steps
needed to achieve com interop, but nothing on what would cause the regasm
error I have encountered.

Any suggestions would be appreciated.

Hi,

Generating a type library for an assembly that references other assemblies
may cause several type libraries to be generated at once. Is your .NET code
referencing some other COM components? Would you please send me the source
code of your .NET class so that I can reproduce the issue on my side?

For the second issue, I think this might be also related to the first one
if you have installed the assembly in GAC.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

I have sent under separate cover my sample project after I whittled it down
to just a couple lines of code. I have also included in the package a file
called "reg.bat" which is what I use to invoke gacutil and regasm. With this
tiny DLL, here is the status:
(1) The call to regasm still generates the "element not found" error.
(2) The ruby -> com -> C# code executes properly.

As far as I observe, my .NET code is not calling other COM components.

Some further results/questions--the final question is the most important:

(1) The regasm call continues to report "element not found" but as that does
not seem to be impacting correct behavior, it is a lesser priority. (If my
supposition is wrong--and it is causing incorrect behavior, then of course it
is first priority.:-)

(2) When I accessed the .NET component via COM from ruby, I was observing
(as originally reported) a failure on the win32ole.new() call indicating a
file was not found (but it did not identify the file!). From experimentation
I found that, instead of calling gacutil and regasm manually, as in :
gacutil /f /i Ruby2net.dll
regasm Ruby2net.dll /tlb:com.Ruby2net.tlb /verbose
if I let VS2005 run regasm (by selecting the "Register for COM interop"
option), then the COM call from ruby worked.
QUESTION: Why this difference?

(3) My reading indicates that VS2005 is only running regasm, not gacutil
(and I have confirmed this by checking that my library is *not* showing up in
the GAC).
QUESTION: So when does one also need to run gacutil?

(4) My COM call from ruby is not quite doing as well as I have led on :-).
It accesses the C# code, but there is a problem in the Windows Communication
Foundation (WCF) connection. It reports that it could not find the endpoint
with the given name/contract. If I create a .NET stub client and call the
same code it works properly, but only because I have given the client an
app.config file that provides the correct signatures under the
<system.serviceModel> node.
QUESTION: So how do I provide the app.config (or otherwise provide WCF
endpoint details) to the COM access path?

Yet a further update:

I still would appreciate answers to my previous questions, but I was able to
get my main issue resolved as I describe below.

I finally realized why my WCF connection was failing: As I stated, I had to
give my .NET stub client a copy of the app.config file, which of course is
not available when I access via COM. Having app.config in the class library
project serves no function. So I simply translated the relevant portion of
the app.config file to imperative code to define the binding, then passed
that binding to the ChannelFactory. That alleviates the client (either .NET
stub or COM interface) from needing the app.config file.

QUESTION: Is there any way to "compile in" the app.config file into my DLL
(which I have attached to the library project in VS) so that I would not need
the hard-coded solution above?

For the original issue, I've been able to reproduce the issue on my side.
After researching, I've found that this issue is related to the GUID that
you're using on the interface. Currently I'm not sure why this specific
GUID "3d17c28b-a52d-46d4-b61c-adab63ee6118" doesn't work, but changing it
to any other GUID will work.

For the other question about app.config, yes it will only be used if you
name it after the main process name. If you are calling it from ruby, maybe
renaming the .config file to ruby.exe.config might work but I haven't
tested and this is actually not recommended. I think you might be able to
embed the config file as a resource in your .NET assembly, then you could
read it and pass the WCF part.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

OK, I just noticed that you're using the same GUID on the interface as in
the Assembly:

[assembly: Guid("3d17c28b-a52d-46d4-b61c-adab63ee6118")]

This attribute will be used to determine the LibID in the generated type
library and cannot be used as an interface's GUID,

Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

(1) I found that after I created a Settings file for my DLL, it generated
myapp.dll.config and those values *were* accessible via
Properties.Settings.Default.xxx even when calling from COM. But if I edited
the myapp.dll.config file, the changes were ignored. I even tried rerunning
the regasm comand guessing that maybe the myapp.dll.config file was somehow
bundled with the dll, but the changes to the config file were still not seen.
How could I get these changes to be seen?

(2) Do I need a Guid attribute on the class, the interface, and the assembly
to expose this for COM access? How do I choose a proper Guid for each?

michael sorens wrote:
I have a managed class which implements two interfaces. Both of the
interfaces have their own GUID and the derived class also has a
different GUID. When you say "proper" I'm not sure what you mean, but
in VS2005 you just go to Tools, Create GUID, and use the Registry
Format, minus the {} braces.

I have an managed add-in working as an Excel UDF. It works fine on my
development system but it's not deploying properly - seems the Setup
Project doesn't include all of the registry entries, or maybe I need
to use regasm with the tlb, like you're doing. The difference between
my code and yours is that I have a COM shim between the Excel/COM
client and my code.

If you'd like to see my setup, I've written a series of blogs on the
topic - unfortunately after 6 articles I still don't have a successful
deployment, but there are a lot of good references for anyone who is
researching this area of interop. I've documented why shim's are
supposed to be helpful for COM interop (with references) and exactly
how to use the COM Shim Wizard from Microsoft (to the best of my
knowledge).

HTH
Tony

remove.mungeNebula-rnd.com/blog/tech/2007/12/excel-tools6.html

Please remove the anti-spam munge from the link.

Hi Michael,

The settings are accessible at first is because the default value are
applied using attributes and saved in the assembly:

[global::System.Configuration.DefaultSettingValueAt tribute("Hello")]
public string Setting {

You can see properties like above in the Settings.Designer.cs file. These
default values take effect when the application .config file is missing or
no value is specified in the application configuration file. In this case,
as I already pointed out, a .NET DLL cannot have its own configuration
file, the .dll.config file has no effect at runtime.

For the GUID issue, if your COM client is using late-bind IDispatch, then
you don't have to specify GUID values for the .NET class/interface. Also,
there's no "Proper" GUID issue as long as they are not duplicated to
existing GUIDs.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.