 |
| C# Programming questions specific to the Microsoft C# language. See also the forum Beginning Visual C# to discuss that specific Wrox book and code. |
Welcome to the p2p.wrox.com Forums.
You are currently viewing the C# section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
|
|
|
|

August 15th, 2007, 10:36 AM
|
|
Authorized User
|
|
Join Date: Nov 2006
Posts: 93
Thanks: 0
Thanked 1 Time in 1 Post
|
|
Calling managed code from un-managed code
I'm working on library modules in .Net 2.0 using C# that will likely be called from unmanaged code, probably VBA from Office 2003 for example.
When I try to reference the .DLL, Excel won't allow it. In the past pre-COM (API) libraries could be accessed by declaring the exported functions in VBA.
I.E.
declare function <exported function name> Lib <library name> (<function arguments>) as <function type>
Does such a protocol exist for managed libraries? Or is there a way to use a managed library similar to a COM library?
What you don't know can hurt you!
__________________
What you don\'t know can hurt you!
|
|

August 15th, 2007, 11:34 AM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
Under the project properties "Build" tab, you check the "Register for COM interop" option. This makes the managed assembly visible to COM. While this works on your development machine when you compile it, when you deploy it you need to manually register it on the destination machine much like you would for a standard COM dll from another programming environment. But instead of using regsvr32 you use the .NET program "regasm.exe" that is found in the appropriate framework directory.
-Peter
|
|

August 15th, 2007, 02:48 PM
|
|
Authorized User
|
|
Join Date: Nov 2006
Posts: 93
Thanks: 0
Thanked 1 Time in 1 Post
|
|
Peter,
It doesn't seem quite that simple. Of course, the fact that I have already built the library and have been using it with a .Net Test application may complicate things some.
When I go back and set the "Register for COM interop" I get the error message "MyLibrary.dll does not contain any types that can be registered for COM Interop."
I need to know how to make the appropriate class/classes available for COM.
What you don't know can hurt you!
|
|

August 16th, 2007, 03:44 PM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
|
|

August 20th, 2007, 12:35 PM
|
|
Authorized User
|
|
Join Date: Nov 2006
Posts: 93
Thanks: 0
Thanked 1 Time in 1 Post
|
|
Peter,
I appreciate your suggestions, but I think the ComVisibleAttribute only exists to make a public entity invisible. According to the links you listed above, "This attribute is not needed to make public managed assemblies and types visible; they are visible to COM by default. "
Unfortunately, my public class is not visible and I cannot figure out why not!
I did try TlbExp, the utility to generate a type library file from a managed .dll but that fails with an "Element not found." error. Editing the AssemblyInfo.cs file and changing the assembly attribute "ComVisible" to true gives the same error.
I also tried creating an interface with the public methods declared and deriving the class from the interface. This also failed.
I don't mean to be obnoxious, but this seems like an important issue to anyone trying to merge managed and unmanaged code.
What you don't know can hurt you!
|
|

August 20th, 2007, 02:34 PM
|
 |
Friend of Wrox
|
|
Join Date: Aug 2003
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
|
|
It certainly is important if you are trying to do it. I have done this once some time ago and don't recall exactly how I got it to work.
-Peter
|
|

August 21st, 2007, 02:08 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 3,074
Thanks: 1
Thanked 38 Times in 37 Posts
|
|
Can you show the code? I have done this a few times with C# libraries for use in COM environments.
--
Joe ( Microsoft MVP - XML)
|
|

August 21st, 2007, 09:32 AM
|
|
Authorized User
|
|
Join Date: Nov 2006
Posts: 93
Thanks: 0
Thanked 1 Time in 1 Post
|
|
My project is rather bulky so I made another to test the idea and resolved the problem! Here is the code for the base project:
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestComAvblty
{
[ComVisibleAttribute(true)]
public class TestComAvblty
{
public TestComAvblty() { }
public void Message()
{
MessageBox.Show("Hello World!");
}
}
}
Note the "[ComVisibleAttribute(true)]" statement. As you will notice, Peter indicated a need for this above. However, the documentation on this attribute is a little confusing.
The key is in the AssemblyInfo.cs file. The AssemblyInfo.cs has all of the standard stuff plus these lines of note:
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
If I set this to "true" on my project, it failed to compile. I think I have the principle down now, I just need to go back to my project and see what the problem is. I do have several enumerations and some public classes that may not need to be public.
I'll start a new thread that's a little more narrowly defined if I continue to have problems with this. Thanks!
What you don't know can hurt you!
|
|
 |