Which file is the COM++ object and how do I import it to .NET?

Question

I'm trying to write a COM++ object wrapper around a Qt widget (control) I wrote so I can use it in future .NET projects. e.g.:

public __gc class comWidget;

In the compile directory are the .exe, an exe.intermediate.manifest, and the comWidget.obj, and also some other crap files (.pdb, etc). So what/how do I import into .NET? I feel like I'm missing an important step for registering the object or whatever, but all these tutorials are terrible outdated and ridiculously unhelpful (for instance, I'm using the old CLR syntax because I can't find any good docs on the new stuff)

Answer 1

Your question is worded so strangely, this can only be a guess, but I going to assume you want to write a user interface component for use in .NET projects. The host program will therefore usually be written in C# or VB.NET, and will be using either the Windows Forms or WPF as its user interface framework. You have some existing C++ code written using C++ with Qt that will do all the implementation for you, so you need to write a Windows Forms or WPF compatible UI widget in C++/CLI where the implementation is a Qt widget, right?

In Visual Studio 2008, start a new project. Pick C++ as the language and choose C++/CLL class library. Put in a dummy class:

public ref class Foo
{
public:
    void Bar() { }
};

Build the project. In .NET the mother-of-all-output is your assembly, which for a library will be a .DLL. Now start a C# project (console application), and add a reference to the DLL you produced above. You can just browse for it on the hard drive.

In the C# project put something like this in the Main function:

var o = new MyClassLib.Foo();
o.Bar();

That's all there is to it. By building the assembly DLL in C++/CLI and then adding a reference to it in the C# project, its public ref class definitions are instantly available. No need to register anything.

Once you have this figured out, you need to decide what you're going to do about integrating a Qt widget (which I'm guessing boils down to a Win32 window handle?) into a .NET UI framework. It will be the most seamless in Windows Forms in which everything is Win32 windows, but you can also get it to work with the newer WPF too as it has a way of bridging in old controls.

This might be what you need to get started: http://msdn.microsoft.com/en-us/library/ms235628.aspx