While implementing my own IFilter I found that most likely some consumers will require marshalling from it. That is they QueryInterface() the IMarshal interface from my object.
Proxy/stubs from MIDL can't be used - MIDL will not compile the filter.idl file - the latter uses custom structures and MIDL doesn't know what to do with them. So it looks like I need to implement marshalling on my own.
Where can I find a guide and samples of how to implement marshaling?
Check out this CodeProject article:
http://www.codeproject.com/KB/COM/CustomMarshaling01.aspx
Related
I've recently had to look for a C# porting of the Protocol Buffers library originally developped by Google. And guess what, I found two projects owned both by two very well known persons here: protobuf-csharp-port, written by Jon Skeet and protobuf-net, written by Marc Gravell. My question is simple: which one do I have to choose ?
I quite like Marc's solution as it seems to me closer to C# philisophy (for instance, you can just add attributes to the properties of existing class) and it looks like it can support .NET built-in types such as System.Guid.
I am sure both of them are really great projects but what's your oppinion?
I agree with Jon's points; if you are coding over multiple environments, then his version gives you a similar API to the other "core" implementations. protobuf-net is much more similar to how most of the .NET serializers are implemented, so is more familiar (IMO) to .NET devs. And as Jon notes - the raw binary output should be identical so you can re-implement with a different API if you need to later.
Some points re protobuf-net that are specific to this implementation:
works with existing types (not just generated types from .proto)
works under things like WCF and memcached
can be used to implement ISerializable for existing types
supports inheritance* and serialization callback methods
supports common patterns such as ShouldSerialize[name]
works with existing decorated types (XmlType/XmlElement or DataContract/DataMember) - meaning (for example) that LINQ-to-SQL models serialize out-of-the-box (as long as serialization is enabled in the DBML)
in v2, works for POCO types without any attributes
in v2, works in .NET 1.1 (not sure this is a huge selling feature) and most other frameworks (including monotouch - yay!)
possibly (not yet implemented) v2 might support full-graph* serialization (not just tree serialization)
(*=these features use 100% valid protobuf binary, but which might be hard to consume from other languages)
Are you using other languages in your project as well? If so, my C# port will let you write similar code on all platforms. If not, Marc's port is probably more idiomatic C# to start with. (I've tried to make my code "feel" like normal C#, but the design is clearly based on the Java code to start with, deliberately so that it's familiar to those using Java as well.)
Of course one of the beauties of this is that you can change your mind later and be confident that all your data will still be valid via the other project - they should be absolutely binary compatible (in terms of serialized data), as far as I'm aware.
According to it's GitHub project site protobuf-csharp-port has now been folded into the main Google Protocol Buffers project, so it will be the official .NET implementation of protobuf 3. protobuf-net however was last updated in 2013, although there have been some commits recently in GitHub.
I just switched from protobuf-csharp-port to protobuf-net because:
protobuf-net is more ".net like", i.e. descriptors to serialise members instead of code generation.
If you want to compile protobuf-csharp-port .proto files you have to do a 2 step process, i.e. compile with protoc to .protobin and then compile that with protoGen. protobuf-net does this in one step.
In my case I want to use protocol buffers to replace an xml based communication model between a .net client and a j2ee backend. Since I'm already using code generation I'll go for Jon's implementation.
For projects not requiring java interop I'd choose Marc's implementation, especially since v2 allows working without annotations.
I use Luabind to manually bind my classes to Lua. Each time I write a new class, I do this binding manually. Is it possible to get a C++ compiler to output the details of a class, its functions, function signatures and overloaded functions' information as XML?
Or write a plugin for a C++ compiler to access this information? I could then use this information to generate the binding automatically.
Has anyone done something similar?
Thanks Ira. I decided to go with CLANG for parsing my C++ code and generating the bindings.
In this related question, I noted that Visual Studio's debugger is able to enumerate the properties of System.__ComObject references, which is "a hidden type used when the wrapper type is ambiguous" -- e.g., the type of object you get when you obtain it from another COM object and don't instantiate it yourself:
Additionally, if you simply write a COM object's identifier into the Immediate Window, its properties and values are similarly dumped:
Note that this is separate from VS2010's "Dynamic View", which I believe uses IDispatch and COM reflection to enumerate the properties of COM objects without the use of PIAs and .NET reflection. The objects I am working with do not implement IDispatch (nor do they implement IProvideClassInfo for that matter), and as such, "Dynamic View" is not able to obtain any information about them:
Interestingly, SharpDevelop's debugger is not able to list the members of System.__Comobjects (e.g. point.Envelope), only strongly-typed RCWs (e.g. point).
So how is Visual Studio able to do it?
I believe in this case, it is because Primary Interop Assemblies exist with definitions for the interfaces supported by these objects, and Visual Studio is likely using reflection to enumerate the supported interfaces and properties. Is that accurate? And if so, how does it work?
For starters, how does it access the PIAs? Does it only look at currently loaded PIAs or does it dynamically load them (and if so, how)? How does it determine which interface, of which there can be many, to enumerate the properties of? It only seems to use one, and not necessarily the first. From the documentation of the API I'm working with (ArcObjects), the default interface for these objects is IUnknown, so it's not just using the default interface either.
In the example in the screenshots, the interface it is enumerating the members of is the IEnvelope interface, which inherits from the IGeometry interface. How does VS2010 know not to enumerate the members of IGeometry instead, which, in my testing, appears first if you just enumerate all the interface types in the PIA? Something very clever going on or perhaps I am missing something obvious?
The reason I'm asking is that the developer of LINQPad appears willing to implement the same functionality if he knew how VS does it. So a good answer here could go a long ways to helping improve that very popular tool.
This is how to do it:
obtain COM object's IDispatch (alternative possible path is IDispatchEx)
obtain a reference to type library -- IDispatch::GetTypeInfo
load type library and enumerate properties
query real object for values for discovered properties
Additional enhancement oipions apply: query IPersist* family of interfaces or IProvideClassInfo to alternatively obtain a reference to typelibrary for the object and discover properties.
I am learning how to implement an out-of-process COM server and came across this Code Project article, Building a LOCAL COM Server and Client: A Step by Step Example.
I can build it, and it runs fine, but where is the proxy/stub DLL? All I can see is the IDL file from which the proxy/stub code is generated during the build. But how is the DLL built, and where is it?
The short answer is that all the interfaces are marked "oleautomation", so oleaut32.dll performs the marshaling, since COM knows how to marshal all the types used in the interfaces.
If "oleautomation" were missing, or a type was specified that COM doesn't know how to marshal by default (see the list here), your nondefault marshaler and its stub would be required.
You need Proxy/Stub project to help COM marshal your interfaces. When you create ATL C++ project with Visual Studio you typically have a secondary project with PS suffix created automatically, and this is your Proxy/Stub DLL. However, you might be doing fine without it at all (I personally never ever had to build and use it, even though I did have to deal with things like custom marshaling). If you provide type library with your project, it is registered and certain conditions are met - COM will supply automatic proxy/stub pair for you.
Bonus reading:
COM Proxy/Stub DLL and why do you need it
When Proxy/Stub Pair is Necessary
For example, if writing a shell extension, is it necessary to register the typelib with CComModule::RegisterServer (i.e., I'm wondering if calling it with FALSE will cause some issues).
Hardly ever.
In theory typelibs would be used by IDEs that wan't to display lists of properties and methods on an object. OleSpy++ or whatever the tool is called can use typelibs to generate quite a lot of important information about the ActiveX
In MSVC you can use #import on a ActiveX with embedded typelib and header files describing the interfaces and types will be automatically generated.
When dealing with well-known interfaces - published in the platform sdk - or if the header files are already supplied for C & C++ bindings, then typelibs are a tad useless.
Even when used from script languages, IDispatchEx now seems to be preferred as a discovery mechanism for the IDE or code to query an IDispatch supporting object at runtime for its methods.
In general, it's fine to say FALSE unless you need a typelib because someone is going to be calling your IDispatch implementation. For most shell extensions I don't think you need a typelib.