I am working on C++/CLI Wrapper for C Static Library.Static Library has 10 function in it.
THis C++/CLI Wrapper will Expose 10 API to C# Application.The Wrapper Will be in the Form of dll.
The Wrapper Will be Used in C# Application.
Now I am trying to add a class in C++/CLi application which will expose function to C# application I am getting Many Option like
C++ Class
CLR Class
a. Component Class
b.Installer Class
c. Windows Form
d. Installer Class
I am bit confused which I need to select out of it as I am new bee in C++/CLI
You need a
CLR Class - Component
since it can be consumed by .NET clients.
CLR class is declared as follows
ref class Wrapper {....}
However in your scenario you could also write a dynamic library and pinvoke the methods from .NET client.
Not sure if your question has been entirely answered, but a Component class creates a class that implements an IComponent interface for remoting/ inter process communication purposes. Didn't seem like what you were looking for.
I think what you were looking for i just a "template" to create a managed class?
In that case all you need to do is select C++ in the wizard and make sure the "Managed" check box on the right hand side is selected.
Related
I'd like to have a managed com object that exposes methods which accept as arguments objects implementing given interfaces. Something like this
[ComVisible(true)]
[Guid(".....")]
class SomeClass {
public void SomeMethod(ISomeInterface arg)
.....
Apparently ISomeInterface should also be declared ComVisible.
Now I want to consume that COM object in a managed client and call SomeMethod there. The problem is I need to instantiate an object that implements ISomeInterface. If that was a native COM object I'd get an interop assembly generated automatically and that won't be a problem. One cannot generate an interop assembly for managed COM object though.
I see that .NET 4.0 introduces the type equivalence concept. It looks like I could generate an interop manually using the ComImport attribute. But that looks like a pretty nasty job. I guess I could also use the TypeIdentifierAttribute but the documentation on that is vague and it says it's mostly intended for use by compilers.
So are there any other ways to do that?
I want to expose a C++ library to a C# application and I decided to take the C++/CLI wrapper approach instead of P/Invoke. The problem that I am now facing is how to expose a templated class in the C++ lib to the C# application using generics.
On the C++ side I have:
template <typename T> class Someclass;
And my goal is to be able to expose the following type to the C# app
class Someclass<T> {}
So the question now is how should my C++/CLI wrapper look like. I tried the naive approach and created a templated type in C++/CLI and naturally I wasnt able to instantiate the class in C# with generic parameters. And if I expose the class as a generic class I wont be able to pass it to C++.
Disclaimer: I am a C++ newbie so please be gentle :)
I am familiar with the differences between generics and templates so no need to explain those. I have this bad feeling that what I want isn't doable, but since I am relatively new to C++ I hope I can somehow achieve it.
AFAIK: You'll have to write a C++ generic.
http://www.codeproject.com/KB/mcpp/cppcligenerics.aspx
I don't see how the C# application would even understand the template being as that is calculated at compile time, so the C# application wont see templates in the DLL.
i was looking for some COM, .NET interoperability topics, and i came across a few legacy COM examples using c++, to round it up, i understood that u define every interface and coclass inside and idl (interface definition file) so other com aware languages can understand type information, but the only com class not defined in an idl file is the one derived from IClassFactory, can some one please tell why since other .NET languages need also to obtain a class factory to instintiate other com classes, so how can they understand the type information ??
Class factories are rarely used directly. In fact, if you needed to create a class factory first to create any COM object, how would you create the class factory itself?
COM library takes care of creating objects. E.g., if COM server is a DLL, it is required to export DllGetClassObject function. When a client wants to create a COM object, it calls CoCreateInstance specifying a CLSID. Using CLSID, COM library finds the server and (if it's a DLL) loads it and calls its DllGetClassObject.
This is just a couple of words on the topic. COM is a very big topic; you might have to start at the very beginning if you want to have complete understanding...
So I've been programming in C# for the last 6 years or so and now I'm getting my feet wet with VB.net.
The code base I'm working with uses some modules. To me the module looks a lot like a singleton. Only one exists; it can be called anywhere inside the namespace.
Is there something I'm missing here? Does VB not support the normal way a singleton is structured (private constructor/public instance field)?
Modules are not a singleton. It is much more akin to a static class in C#. If you decompile the code you will see they have a very similar structure (modules have an extra attribute).
The major differences between a C# static class and a VB.Net module are ...
Don't have to add Static / Shared qualifiers to methods in a module. They are Shared by default and you cannot change this
If a Module is in an Imported namespace, all of its methods are available without qualification.
Static classes in C# can be generic, modules cannot (although they can have generic members)
If I'm not mistaken, a VB module is the same thing as a static class.
I have Excel add-in which I add so many class modules that it is now very bulky. I want to convert it into a type library or a COM package so that I can re-use it for the other apps in the MS Office suite.
I ported the add-in to Visual Studio as a class library project but Excel Automation doesn't recognize the classes in the compiled .dll file. Intuitively I think I would need a manifest, an interface or the something like that in my code.
What do I need to know in order to expose a class's methods and properties for use in OLE Automation?
I am assuming since you used the phrase manifest, you are assembling this DLL using a .net development platform VS2003, VS2005 or VS2008 as compared to a VS 6.0
This link provides a detailed set of steps required to register a .NET assembly for use as COM component.
The one thing the article doesn't mention that I routinely do is create my own GUIDs. Use the Create GUID item in the Tools menu then insert them above the classes, interfaces, and enums you want exposed for COM.
[Guid("3838ADC1-E901-4003-BD0C-A889A7CF25A1")]
public interface IMyCOMClass {
void MyMethod();
}
[Guid("476BDEB6-B933-4ed5-8B86-7D9330A59356"),
ClassInterface(ClassInterfaceType.None)]
public class MyCOMClass : IMyCOMClass {
public void MyMethod() {
//implementation here
}
}
The second thing I do is use a separate interface for the COM portion that is implemented by the class. The reasoning for doing this has to do with the breakability of COM when the interface changes, think DLL Hell.
Hope this helps,
Bill.
(Assuming it's a .NET project)
Besides having to add the Guids to your interfaces and classes, you also need to mark them with the ComVisible attribute (unless you've marked the whole assembly with it). Also, you need to use the tlbexp.exe to export the metadata as a COM typelibrary for referencing in unmanaged clients.