Develop Reference

Is there a cleaner method of making COM visible applications?

Given a specific class:
public class Klass
{
public int value;
public void doSomething(){
return;
}
}
To make said class COM visible, as far as I know, one needs to do a few things:
Import System.Runtime.InteropServices
Create an interface for the class.
Extend the interface created.
Create 2 unique GUIDs, one for the Interface and another for the class.
Add Dispatch IDs to the interface.
Producing something like:
[Guid("EAA4976A-45C3-4BC5-BC0B-E474F4C3C83F")]
public interface IKlass
{
[DispId(0)]
public int value;
[DispId(1)]
public void doSomething();
}
[Guid("0D53A3E8-E51A-49C7-944E-E72A2064F938"),
ClassInterface(ClassInterfaceType.None)]
public class Klass : IKlass
{
public int value;
public void doSomething(){
return;
}
}
The resulting code looks utterly gross in my opinion... The question is, is there a simple cleaner method of creating these COM interfaces? I can imagine modifying the build process myself to give a interop feature. E.G.
public interop class Klass
{
public interop int value;
//...
}
However, this is non-standard, which has it's issues as well. Is there anything built-in to Visual Studio / C# that I can use to make building COM interfaces easier/cleaner?

As suggested by Zohar Peled the best way is to use RegAsm.exe:
Create some C# class library "TestProject":
using System.Windows.Forms;
namespace TestProject
{
// Note. Only public classes are exported to COM!
public class Test
{
// Note. Only public methods are exported to COM!
public void testIt() {
MessageBox.Show("Yellow world");
}
}
}
IMPORTANT:
Only public classes are exported to COM. And only public methods of these classes are available via a COM object instance.
Sign the project.
In AssemblyInfo.cs set [assembly: ComVisible(false)] to [assembly: ComVisible(true)]. Note: You can also use attribute [ComVisible(true)] before each class you want to expose to COM. This just sets the default to true making it easier to work with if building an API
Build the project.
Run regasm. Remember to use the correct version of Regasm (32-bit/64-bit) and the version for your .NET framework:
# .NET v4.5 64-bit
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" -tlb -codebase "C:\Users\sancarn\Desktop\tbd\TestProject\TestProject\bin\Debug\TestProject.dll" -verbose
# .NET v4.5 32-bit
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" -tlb -codebase "C:\Users\sancarn\Desktop\tbd\TestProject\TestProject\bin\Debug\TestProject.dll" -verbose
...
Regasm should output something like this:
Microsoft .NET Framework Assembly Registration Utility version 4.7.3056.0
for Microsoft .NET Framework version 4.7.3056.0
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Type 'TestProject.Test' exported.
Assembly exported to 'C:\Users\sancarn\Desktop\tbd\TestProject\TestProject\bin\Debug\TestProject.tlb', and the type library was registered successfully
Now you can test the file in VBScript for example:
Dim o As Object
Set o = CreateObject("TestProject.Test")
Call o.testIt

Sancarn answers your question, but note that this makes ALL COM-compatible classes in your project COM-visible as well, which you might not want (see here and here). If you do not explicitly set the UUIDs you are opening yourself up to problems when you deploy if you access the classes with early-bound clients like VB or VBA (not VBScript, which is late-bound).
Yes it's not "clean" but neither is COM, especially when you want to expose it to late-binding clients live VBScript.
I would also change your public field to a property, which is more standard for public members:
[Guid("EAA4976A-45C3-4BC5-BC0B-E474F4C3C83F")]
public interface IKlass
{
[DispId(0)]
public int value {get; set;}
[DispId(1)]
public void doSomething();
}

Automation error on VBA using an imported custom C# class

I'm trying to use a class on Access VBA 7.0 which implements an Interface I made and I'm still getting "Automation error" even after adding the usual headers.
DropBox.cs
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("E2F07CD4-CE73-4102-B35D-119362624C47")]
[ComDefaultInterface(typeof(ICloudFileProvider))]
[ProgId("CloudFiles.dll")]
public class DropBox : ICloudFileProvider
{
public DropBox()
{
ConectaDropbox("TokenLongChicken");
}
public DropBox(string tokenUsuario)
{ //This was the original and good constructor. I know I can't use constructors with arguments on VBA. Just keeping it to compile with Test
ConectaDropbox(tokenUsuario);
}
public void ConectaDropbox(string tokenUsuario)
{
}
// This method and others come implemented from an interface (ICloudFileProvider)
public string SubirArchivo(string rutaLocal, string carpetaCloud, Tipos.TipoSobreescritura tipoSobreescritura)
{
}
This didn't work, so I saw I have to "create" a header for the Interface and I did it on the Interface itself. I'm still getting the error, so on the DropBox class, I added another header "enumerating" the methods I'm using on this class (which has no sense, but I've read another questions on SO which concretes you have to do so).
So I added this at the end of the DropBox class, noting it is as well on the ICloudFileProvider Interface (the real one).
[ComVisible(true)]
[Guid("E2F11CD4-CE73-4102-B35D-119362624C47")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IExposedClass
{
void DropBox();
void DropBox(string tokenUsuario);
void ConectaDropbox(string tokenUsuario);
string SubirArchivo(string rutaLocal, string carpetaCloud, Tipos.TipoSobreescritura tipoSobreescritura);
decimal ConvertBytesToMegabytes(long bytes);
void Descargar(string link, string carpetaLocal);
string GenerarLink(string rutaCloud);
void EliminarArchivo(string link);
}
I guess I'm doing something wrong but I'm kind of lost in this DLL and TLB hell. This project just works fine on C# but I need to integrate it on VBA and I see no examples with projects which uses real interfaces. I'm not really sure if the "InterfaceIsIUnkown" I add at the end of the DropBox class makes any sense, but I saw it on every example I found on the Internet (but none of them used a real Interface).
Could anybody help? Thanks.
P.S: yes, I perform the RegAsm.exe export to .TLB and then I add it to my Access, with no export errors apparently.

VBA object browser doesn't show class members in my .NET dll library

I'm trying to make a simple (no dependencies) .NET dll file that is accessible from VBA (MS Office). I'm using VS2015 Express, and make my dll the simplest way possible: Create a class library, add a simple class, and check the options "Make assembly COM-visible" as well as "Register for COM interop".
My C# code:
namespace TestLib {
public class Hello {
public int timestwo(int i) {
return 2 * i;
}
}
}
The library is added to the Windows registry automatically on build. I can access it from Tools --> References within the MS Office VBA editor, and the following VBA code works as expected:
Sub test()
Dim h as TestLib.Hello
MsgBox h.timestwo(2)
End Sub
Now the funny thing is: The object browser shows my class, but with no member functions! And consequently, the autocompletion feature does not work... What is going on here?

Mmm, your description of what you did is missing a few steps, it appears to me. You need GUIDs. You need an Interface, which your class needs to implement. And you need to specify how the class should work with the Interface. It needs to be set to the Type "None" for the Intellisense, etc. to work.
Here's an extract from a .NET COM DLL of mine which does appear in the Object Browser and gives Intellisense when referenced for a VBA project.
[Guid("149F7A5F-7DAC-4426-8AA0-28975A2CE203")]
[ComVisible(true)]
public interface ITest
{
string testLT(string FilePath, object Args);
string RemoveListTemplates(string FilePath, object Args);
void test(string arg);
}
[Guid("D86307C2-3FFA-4518-BABC-DA5F26ABC445")]
[ClassInterface(ClassInterfaceType.None)]
[ComVisible(true)]
public class Test : ITest

In VS, you need to add XML comments to your code:
namespace TestLib {
public class Hello {
/// <summary>
/// A method to return value * 2
/// </summary>
/// <param name="i">An integer to multiply by two</param>
public int timestwo(int i) {
return 2 * i;
}
}
}
Then make sure the tickbox for XML Documentation File is checked and ensure the XML file has the same name as your assembly. This should supply the meta data needed to populate the IntelliSense feature.

C# and com for vb6

I have an issue with C# and COM.
[Guid("f7d936ba-d816-48d2-9bfc-c18be6873b4d")]
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
public class Process : IProcess
{
public Process()
{
}
public int UpdateBalance(string accountNumber, string adminEventDescription, decimal curAmount)
{
return 10;
}
}
[ComVisible(true)]
[Guid("5c640a0f-0dce-47d4-87df-07cee3b9a1f9")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IProcess
{
int UpdateBalance(string accountNumber, string adminEventDescription, decimal curAmount);
}
And the VB code
Private Sub Command1_Click()
Dim test As Object
Set test = New Forwardslash_PlayerTrackingSystem_Api.Process
End Sub
I get the following,
ActiveX component can't create object?
Any ideas on how to fix the issue?

Have you ticked the "Register for COM interop" box in the project properties?

Do you have the ProgID Forwardslash_PlayerTrackingSystem_Api.Process defined in the C# source as well? Your example code does not seem to include it. (Or are you working with an existing type library and creating the object in VB by GUID somehow?)
And is the C# component registered correctly in the registry on the machine where the VB code runs? See the answer by Paolo for a way to have VisualStudio do this for you when you build and/or register it yourself using the regasm.exe tool. This tool is equivalent to regsrv32.exe for "real" COM objects, but then registers an appropriately built .NET assembly in the registry for use from COM.

Your [InterfaceType] attribute is wrong. VB6 requires an IDispatch interface, it cannot handle an IUnknown interface. It likes ComInterfaceType.InterfaceIsDual best, that produces a full type library, enables IntelliSense in the VB6 editor and is roughly a 1000 times faster than the late-bound IDispatch.

Using regasm's /codebase switch is mandatory if the assembly is not registered in GAC.

warning MSB3391: <DLL> does not contain any types that can be unregistered for COM Interop

I've made a simple C# DLL (that's part of a much larger project) using VS2005. I need to use the DLL in Excel via VBA code so I am using COM Interop on the assembly. I am trying to make the build process automatically generate the necessary TLB file so that I don't need to go to the command line and use regasm after every build.
My problem is that although the DLL compiles and builds fine, it does not generate a TLB file. Instead, the error in the title prints out in the output box.
I've gotten other DLLs to build TLB files by going to the project's properties in VS2005 -> Build -> Output -> Check "Register for COM interop". Also I have [assembly: ComVisible(true)] in the AssemblyInfo.cs.
Here's the summary of the source for the problem DLL and the DLL that it references for a return type:
using System;
using System.IO;
using System.Runtime.InteropServices;
using SymbolTable;
namespace ProblemLibrary
{
public class Foo
{
public Foo(string filename)
{
...
}
// method to read a text file into a SymbolTable
public SymbolTable BuildDataSet(string[] selected)
{
...
}
}
}
Here is a summary of SymbolTable.dll. It holds a return type that ProblemLibrary uses.
using System;
using System.Collections.Generic;
namespace SymbolTable
{
public class SymbolTable
{
readonly Dictionary<SymbolInfoStub, string> _symbols = new Dictionary<SymbolInfoStub, string>();
/*methods that interact with Dictionary snipped*/
}
}

You need to have ctor without any params.
You should have GuidAttribute and ProgIdAttribute around the classes.
Its better to mark the assembly as ComVisible(false) and mark explicitly the classes that need export.
Use interfaces for your classes.
Make sure the you have GuidAttribute in the assembly level.
[Guid("<PUT-GUID-HERE-1>")]
[ComVisible(true)]
interface IFoo
{
void DoFoo();
}
[Guid("<PUT-GUID-HERE-2>")]
[ComVisible(true)]
[ProgId("ProgId.Foo")]
class Foo : IFoo
{
public void DoFoo()
{
}
}

In the AssemblyInfo.cs file, make sure you have the following:
// 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(true)]
UPDATE:
Read: How can I make use of .NET objects from within Excel VBA?
Which links to:
http://richnewman.wordpress.com/2007/04/15/a-beginner%E2%80%99s-guide-to-calling-a-net-library-from-excel/

I saw a similar problem. I got an error like:
warning MSB3391: does not contain any
types that can be unregistered for COM
Interop.
I followed all the rules (ComVisible, etc.) but nothing worked.
Solution: I had to put something in the default constructor so that it would not be optimized away. The moment I had something there, the registration finished with no message and the component was visible in the registry.
Interesting note: a friend of mine managed to register the original DLL with the empty default constructor on his machine (64-bit Windows-7, VS2008-Professional, like mine). However, his REGASM.EXE was:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm.exe
while mine was:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe
So it could be some difference between versions of the .NET framework - maybe the later version is optimizing too much and the REGASM does not account for that.