1

I've created C# library, but then occurred that it is also needed for some unmanaged C++ solution. I created COM interface (extracted Interface, added GUIDs, created keys, registered and so on).

I've created C++ library which uses tlb file, and creates tlh file. Currently I'm creating some simple UI to check if this wrapper works. My question is - what should I provide to the customer because I have doubts about this "signing" process of COM object. I have to deploy now - one C# library and its wrapper written in C++ (with .h, .lib and .dll - maybe something more?). I don't know if it will start, when it is not registered in user's system? How to handle it that when user get some files he is able to work with them immediately?

Improve this question

2 Answers 2

Reset to default
3

No, your customers don't need this "C++ wrapper". They can easily generate one themselves, the #import directive in MSVC++ does it automatically for example. It isn't necessary for them to use C++ anyway, COM works in any language. If you include anything at all then consider a demo program that demonstrates how the interface works, also lets them check that everything is installed correctly and in working order.

What your customer needs is the type library, a .tlb file that describes the interface and can be read by most any compiler. Like the #import directive in MSVC++, Project + Add Reference in a .NET project. A type library is the exact same thing as metadata in a .NET assembly. And in the case of a C# [ComVisible] assembly, it is automatically generated from .NET metadata, you run Tlbexp.exe on the assembly. Your customer can do this too, it is better if they do so there's a guaranteed match between the .tlb. But you can do it for them if they are unfamiliar with .NET tooling.

Only thing you must do is write an installer so the assembly is properly registered on the customer's machine. Same thing as Regasm.exe does. Strongly favor the GAC for [ComVisible] assemblies, COM has a nasty DLL Hell problem.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

You need to create an installer that registers your assembly in the target machine. If you create an msi installer, in the file system editor there is a register property with different options for COM registration. The msi can detect the dependencies of your project output. You can start reading here:

http://msdn.microsoft.com/en-us/library/cc766795.aspx

Improve this answer

2 Comments

I'm not specialist with C++ - if the user register it with the installer - how it would be possible to use this registered COM interface, when now I have direct link to .tlb file, and I assume even when some .tlb file will be available (or something like that) how the C++ wrapper would to know where it is registered and how to link to that? Currently I'm using #import "<PATH>\file.tlb";
@KrzysztofDziądziak The user can generate the tlb file using the Type Library Exporter tool. The wrapper will get the relevant data from the system registry. msdn.microsoft.com/en-us/library/hfzzah2c(v=vs.110).aspx

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.