When I port a NDepend CQLinq query to C# I must allways start defining a codeBase to query to, so this CQLinq query
from m in Methods
where m.ILCyclomaticComplexity > 10
select new {m}
using NDepend API in C# I must port to:
ICodeBase codeBase
from m in codeBase.Application.Methods
where m.ILCyclomaticComplexity > 10
select m
I see there is a ICQLinqExecutionContext. Can I define the context for the queries so I can directly use Assemblies, Methods, JustMyCode, ...etc?
Thanks!
As explaine in the ICQLinqExecutionContext doc: This interface is reserved for CQLinq implementation usage and is not intended to be used in your code.
But as you noticed, with just a little bit of rewritten, you can access 100% of CQLinq features (like using codeBase.Application.Methods intead of just Methods)
Also by reading the CQLinq syntax doc about predefined domain, you can see that a domain like Methods in CQLinq gets translated to context.CodeBase.Methods at CQLinq post-compilation time. What you are really missing is not the interface ICQLinqExecutionContext but CQLinq post-compilation time that is not available in C#.
Related
I want to use the COM object with the progID Windows.Contact.1 via ActiveScripting (JScript, VBScript, Python, etc).
This COM resides in C:\Program Files (x86)\Common Files\System\wab32.dll. It seems, there is no TypeLib available for it. The COM delivers, amongst others, IContact for the "Windows Address Book" (storing contacts as XML in folders, as in Windows 7). IContact is documented here.
In JScript I did:
var co = new ActiveXObject("Windows.Contact.1");
typeof co; // results in: unknown
Since it results in unknown, I have the suspicion, that this COM could not be usable for scripting. Somewhere I read, that everything, that inherits from IUnknown can not be used for scripting, instead it must inherit from IDispatch. But I am unsure, as to how much of this is valid, and whether there are workarounds.
I would like to ask for acknowledgement of my suspicions (since I am new to all of this and have no C++ or C# background) or to ask for a way, as to how to use Windows.Contact.1 from scripting, including a way, to find out, which methods/objects I can use, without resorting to a TypeLib.
I have access to pages like Programming Windows Contacts and related ones, but first I need to get an instance in ActiveScript (JScript, VBScript, Python, Lua will do). I also have access to applications like "MS OLE View" and "OLEView DotNet". Thank you.
There are entire books on the subject, but here's a very simplified story. There are basically 3 "categories" of COM interfaces:
Interfaces deriving from IUnknown
aliases for programming against: early binding, (custom) vtable binding
the simplest way to implement a COM "server"
it's only a binary contract (methods layout, method signature, parameters behavior like in/out for cross-apartment/process support, ...)
you need to somewhow tell your callers what is this binary contract you support (you can use .idl, .tlb or anything that your caller can understand)
there are some official ways of documenting your IUnknown-derived interfaces: .idl -> .h and .tlb is the most standard one
only supported by a certain class of languages (for example C/C++, .NET, Delphi), those who understand .tlb (or .idl, or equivalent .h), or those who allow redefining layout manually (like .NET). You can perfectly define a language that can do that w/o ever using .tlb. That's the beauty of COM, it's just a binary contract.
if your language doesn't support it, you just can't use it, you'll have to write or use a wrapper with a language that supports it and exposes it in a way your language supports. Powershell for example doesn't support IUnknown-derived interfaces (I'm not 100% sure) but supports .NET so it can use .NET as a "super wrapper".
IDispatch interface
only requires one IUnknown well-known interface implementation: IDispatch
aliases for programming against: late binding, OLE automation, COM automation, or simply Automation (not to confuse with UI Automation)
invented for higher level languages (VB/VBA first, ActiveScripting a bit later)
only supported by a certain class of language, and the way it's supported varies (for example it's supported in C++ of course but it's not super easy w/o wrappers or tooling like Visual Studio's C++ #import directive). JScript and VBScript don't exactly support the same set of features with regards to Automation.
you're supposed to use only a predefined list of types "Automation-Compatible types":
these types where initially very related to VB/VBA (VARIANT, SAFEARRAY, BSTR which means "Basic String"...)
from the higher level language, it really makes COM much transparent and easier as that was the whole point (and can make it harder from the lower level ones...), it also allows "syntactic sugar" niceties
note the IDispatch implementation can be very dynamic and really late-bound at runtime (get id of name -> invoke) but most available programming tooling quite freezes the list of ids/names at compile time (ex: .NET) because they support Dual interfaces.
Dual interfaces:
interfaces that implement a custom IDispatch-derived interface and implement IDispatch itself to match the custom interface (both implementations supposedly being "equivalent" of course). Have a look at the link below, it has nice images.
because of IDispatch, you're supposed to use only Automation compatible data types in the IDispatch-derived method.
it's more work to implement (so it's usually done by programming tools, for ex: ATL)
a bit easier for native (C/C++, etc.) callers (no need to use IDispatch wrappers) but you still have to digest automation data types
IMHO, one of the best 1-page introduction to COM is here: Introduction to COM
What makes programmatic introspection/reflection easier in virtual machines rather than native code?
I read somewhere that VMs by nature allow for better introspection/reflection capabilities but I cannot find more information about it online. Would like to know why.
I believe you mean higher-level languages vs lower-level languages instead of virtual machines.
Higher level languages like Java and C# have implemented reflection and introspection, so there are functions available to the developer to use this information.
Languages like C do not have any pre-built reflection capabilities.
Reflection is very expensive (time-consuming) for any language to run, and should not be used in code that needs to be extremely fast.
Programmatic introspection essentially means to examine & inspect the current call stack, or the current continuation. (Read Appel's book: Compiling with Continuations).
Few programming languages provide this ability. Scheme's call/cc reifies the current continuation, but give no standard ways to inspect it.
The current call stack might be inspectable (e.g. see GCC __builtin_return_address as an ad hoc example).
Most compilers (but not all) do not have an easy way to give information about the layout of the current call frame (however, the debugger DWARF format contains it).
And optimizing compilers (e.g. for C) usually don't give access to the offset of some local variable in the call frame (even if the compiler computes this offset). BTW, the same stack slot might be reused for different variables; read about register spilling.
See also J.Pitrat's CAIA system - the generated C code is able to organize the stack to be able to inspect it;
In a bytecode VM like JVM or NekoVM or Parrot, introspection is easier because each local variable has a well defined slot in the call frame. This is not the case for most compiled languages (e.g. C or C++) because the compiler is able to reuse (for optimization purposes) some slots, or even put a variable only in some machine register, without even allocating any call stack slot to spill it.
Two simple COM IDL file questions I can't seem to find answers for, even with searching MSDN and the general internet:
Is there an interface attribute which lets me specify my interface is to be implemented by STA objects only, or is this a detail for my documentation alone? I already have [object, local] which I think is correct for non-remoting (in-process) COM objects.
Do I need void in the parentheses of my method declarations (like in C) to specify no arguments? MSDN is inconsistent about this; so are header files. My own personal implementations of this interface will be in C.
Thanks.
You are talking about the threading model you want to specify for your COM component. No, you cannot put that in the IDL, it is far too important. A client doesn't have to use your IDL, a scripting language like Javascript never will for example. It must go in the registry, in the CLSID key for your component. You want ThreadingModel = "Apartment" to request the client to provide an STA thread. If it is missing then COM assumes that by default.
Do keep in mind that this does not force the client programmer to provide one. If he favors MTA for some reason then COM will provide the STA thread to give your component as safe home. If your proxy makes it too slow to be usable then you do have a documentation requirement.
No HRESULT Method(void) in the IDL is not necessary, using HRESULT Method() is sufficient. Midl.exe doesn't care what language you use.
I'm programming Windows COM in C++ and I see that a lot of functions get prefixed with :: so that the global namespace version got called. Why is that?
I understand that there may be conflicts with namespaces, but does it happen so often in COM that everyone has become so paranoid that every single function now has to be resolved explicitly?
Here are some examples that I see often:
wStrLen = ::SysAllocStringLen(NULL, wStr);
::SysFreeString(str);
::CoTaskMemFree(item);
And many others.
It just puzzles me why the programmers chose to resolve namespace explicitly and why they didn't just write:
wStrLen = SysAllocStringLen(NULL, wStr);
SysFreeString(str);
CoTaskMemFree(item);
Any ideas?
No, that's not common in COM programming, not in any I wrote or studied anyway. COM itself adds few names to the global namespace, there are not that many helper functions. A common way to implement a COM interface is to use a C++ class, you can stick it in any namespace you like since it doesn't get exposed at all outside of the module. I suspect that it is just something the team whose code you saw preferred. If you saw it in a book then that's a good way to increase the odds that the book code sample can drop into an existing program without too much trouble. There's otherwise nothing wrong with it.
To implement "method-missing"-semantics and such in C# 4.0, you have to implement IDynamicObject:
public interface IDynamicObject
{
MetaObject GetMetaObject(Expression parameter);
}
As far as I can figure out IDynamicObject is actually part of the DLR, so it is not new. But I have not been able to find much documentation on it.
There are some very simple example implementations out there (f.x. here and here), but could anyone point me to more complete implementations or some real documentation?
Especially, how exactly are you supposed to handle the "parameter"-parameter?
The short answer is that the MetaObject is what's responsible for actually generating the code that will be run at the call site. The mechanism that it uses for this is LINQ expression trees, which have been enhanced in the DLR. So instead of starting with an object, it starts with an expression that represents the object, and ultimately it's going to need to return an expression tree that describes the action to be taken.
When playing with this, please remember that the version of System.Core in the CTP was taken from a snapshot at the end of August. It doesn't correspond very cleanly to any particular beta of IronPython. A number of changes have been made to the DLR since then.
Also, for compatibility with the CLR v2 System.Core, releases of IronPython starting with either beta 4 or beta 5 now rename everything in that's in the System namespace to be in the Microsoft namespace instead.
If you want an end to end sample including source code, resulting in a dynamic object that stores value for arbitrary properties in a Dictionary then my post "A first look at Duck Typing in C# 4.0" could be right for you. I wrote that post to show how dynamic object can be cast to statically typed interfaces. It has a complete working implementation of a Duck that is a IDynamicObject and may acts like a IQuack.
If you need more information contact me on my blog and I will help you along, as good as I can.
I just blogged about how to do this here:
http://mikehadlow.blogspot.com/2008/10/dynamic-dispatch-in-c-40.html
Here is what I have figured out so far:
The Dynamic Language Runtime is currently maintained as part of the IronPython project. So that is the best place to go for information.
The easiest way to implement a class supporting IDynamicObject seems to be to derive from Microsoft.Scripting.Actions.Dynamic and override the relevant methods, for instance the Call-method to implement function call semantics. It looks like Microsoft.Scripting.Actions.Dynamic hasn't been included in the CTP, but the one from IronPython 2.0 looks like it will work.
I am still unclear on the exact meaning of the "parameter"-parameter, but it seems to provide context for the binding of the dynamic-object.
This presentation also provides a lot of information about the DLR:
Deep Dive: Dynamic Languages in Microsoft .NET by Jim Hugunin.