I know it's a bit old school, but I have to translate an LDAP function written in VB (Visual Basic not .net). And using managed code I can't produce the same result.
To solve the problem quickly I would like to use COM (Component Object Model) exactly as the Visual Basic function is doing like this:
set dso=GetObject("LDAP:")
I'm completely out of practice with COM, what DLL would I need to include as a reference to make it work?
I believe Marshal.GetActiveObject is the equivalent to the VB GetObject call you are used to using.
This will return you the object, you then need to either:
Reference an interop assembly with the type definitions for your LDAP object
Make the calls to the object using reflection invoke
Use the dynamic keyword in C# 4.0 to make the calls to the object using a late bound mechanism, similar to what VB did
I recommend using option 3 if you are using .Net 4.0
Related
Has anybody tried to use C++/winrt to create Win32 COM objects? The C++/winrt docs document that consuming them is possible and of course creating "new" UWP COM objects. I was wondering if for some simple scenario's one could use the C++/winrt headers instead of ATL to generate some simple COM objects.
You can write a COM component with C++/WinRT. Here’s an example of a COM executable server but the principles and techniques are much the same for a DLL.
https://gist.github.com/kennykerr/d983767262118ae0366ef1ec282e428a
For a DLL you just want to make sure you export an implementation of DllGetClassObject and DllCanUnloadNow. Otherwise, its just like any other DLL and you can use the winrt::implements class template to implement the various classes and factories.
I have a number of functions that look basically like…
Public Function Keys() As Dictionary(Of Integer, myData).KeyCollection
I'm trying to expose this class to COM so I can use it in Excel, but VS complains that…
Warning: Type library exporter encountered a generic type instance in a signature. Generic code may not be exported to COM.
I think this means I have to copy this to a type that can be exported to COM, I suspect a SAFEARRAY of strings?
Anyone have an example code of this?
You cannot expose generic types to COM, it has no support for it whatsoever. The reason that Dictionary doesn't have the [ComVisible(true)] attribute. Somewhat intuitively obvious, languages like C++, scripting languages like VBScript or Javascript, VB6 and VBA, etc, don't know beans about .NET generics. Only a .NET program can ever use it, you don't need COM interop for that.
If you want to expose a dictionary then you'll need to create your own or simply fall back to the olden Hashtable. Which is [ComVisible], your type library will automatically include mscorlib.tlb
I have followed the example here: http://msdn.microsoft.com/en-us/library/vstudio/jj822931.aspx to create an In-proc Classic COM DLL using Windows Runtime Template Library (WRL). I am also able to modify to code to run the DLL as COM surrogate (wrapped inside DllHost.exe).
However, I couldn't find the way to create an out-of-process COM EXE using the WRL. There is a simple example using barebone COM API here: http://www.codeproject.com/Articles/3173/A-simple-yet-debuggable-COM-skeleton-code, but I'd like to know how I can utilize WRL to simplify that.
Thanks.
Yes it is possible. I just got one working. Here's the basics that are required, as compared to implementing an in-proc coclass.
Implement your coclass using WRL::RuntimeClass the same way you would for an in-proc class. (https://msdn.microsoft.com/en-us/library/jj822931.aspx)
In your main function, create a module object using WRL::Module<OutOfProc>::Create(), and call module.RegisterObjects() on startup, and module.UnregisterObjects() and module.Terminate() on shutdown.
You need to build a DLL to host the proxies: https://msdn.microsoft.com/en-us/library/windows/desktop/ms688707(v=vs.85).aspx
Static Registrations: DO register the Interface and the CLSID of your proxy stub. DO NOT statically register your coclass.
In the Client, when you call CoCreateInstance, be sure to use the appropriate CLSCTX. (I use CLSCTX_ALL when the hosting model is not important to the client.)
(I know it's been almost 4 years, but I had the same question this week.)
I have several ATL COM services and would like each of them to have their own namespace, but be under a single base namespace, just like the System namespace in .NET.
For example if a C# project were to include these COM objects, all would be under the same base namespace:
using MyCompanyName.Terminator;
using MyCompanyName.Superman;
using MyCompanyName.Thor;
... instead, what I have currently is this:
using Terminator;
using Superman;
using Thor;
... which is what I do NOT want. I want to be able have a base namespace and sub-namespaces under that base. I don't know how to do this when creating an ATL service and what I need to modify to do this. Is it something I modify in the IDL file?
In case you are targeting managed clients it is possible to provide namespaces for them! However since COM is language independent you cannot provide namespaces using the interface description (type library). But whenever you are creating managed wrapper assemblies (that are actually referenced by the client), they can have namespaces to address the RCW objects. The keyword you are looking for is Primary Interop Assemblies. Those are assemblies that you as the vendor of the original library provide for clients to reference. To simplify this: You are doing the work, Visual Studio does for you when you are adding a reference to a COM library. You are creating the interop assembly and the customer does not reference the type library, but the assembly you generated. Using the tlbimp.exe tool it is possible to encapsulate the RCW types inside a namespace using the /namespace parameter.
I need to use a COM object in my .NET 2.0 compact framework project, but I can't use the CreateObject function. Is there any other way to call a COM object that will work in my environment?
You'll need to call CoCreateInstance(). You can find a P/Invoke declaration for it here. If you only have a ProgID then you need to call CLSIDFromProgID() first. Make sure you've exhausted all possibilities of finding a type library for the COM server (Tlbimp.exe), this kind of code isn't easy to get right.