A number of people (see this and this for starters) have reported weird behaviour with ComponentCheck.exe which is used as the prerequisite checker for the VSTO Office 2007 PIA redistributable package that was added in Visual Studio 2008 SP1.
For those of you unfamiliar with how the setup.exe is created when an add-in is published, it may come as a surprise to learn that ComponentCheck.exe ends up being embedded directly into setup.exe. When setup.exe is run on the target machine, ComponentCheck.exe is unpacked to a temporary directory and run from there.
If you're running into unexpected behaviour (e.g. the PIA installer running when you believe it shouldn't or, conversely, the PIA installer not running at all when you believe it should), you might want to try testing ComponentCheck.exe by copying it from the %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\Office2007PIARedist directory on your Visual Studio 2008 SP1 dev box to an arbitrary location on a test machine and running it from a batch file as follows:
@echo off
ComponentCheck.exe
echo %ERRORLEVEL%
This just serves to run the program and echo its output/return value to the console. This script should echo 1 if the PIAs are already installed or 0 otherwise. The PIAInstallAction property is set to this return value and used to block or enable installation of the PIAs respectively (see the <BypassIf Property="PIAInstallAction" Compare="ValueNotEqualTo" Value="0" /> element in product.xml). You might want to consider trying this a machine with Office 2007 PIAs installed and another machine without the Office 2007 PIAs installed.
If you're seeing genuine issues with this component after running this short test, please don't hesitate to let us know.
Some items on VSTO compatibility including my own compatibility matrix:
Well, first of all I started as a part-time graduate student at the University of Washington in the Professional Master's Program in computer science and engineering. This is very exciting and I'm learning a lot of interesting things particularly in the areas of functional programming languages (as you may have figured given my previous references to F# and OCaml) and complexity theory. I've also signed up for Seattle Startup Weekend 2 which I should definitely plug since Microsoft is the national sponsor. That's next weekend and I'm really looking forward to it.
What else? Well, in parallel with this, my MSDN blog, I've also started working on my personal blog. This I decided to keep separate since the main subject of my posts on this site, while still primarily of a technical nature, mainly revolve around the interesting challenges associated with writing the actual blog code from scratch. So there.
Anyway, I do plan to post here more often soon.
So, I decided that Objective-C is not that interesting for the time being. I thought I'd play with
F# instead. More on this later…
I switched on my Mac for the first time in about three months this evening. I had a hankering to do some Objective-C. This is a language I've tried to master before but without huge amounts of success. However, with my renewed interest in late binding and dynamic languages, I think it's time to start looking again. And this time it's absolutely going to happen. Before I switched on the Mac I tried the Portable Object Compiler and MinGW port of GCC on my Windows box but couldn't get either of them to compile my sources without the compiler crashing due to segmentation faults (caused by exception handling, I believe). Not cool. Anyway, I'm back in Mac land and having fun.
So I thought long and hard about my initial stab at a multimethod implementation for C#. It was a reasonable proof of concept. However, I read some more on the subject of multiple dispatch and the visitor pattern and came up with a few additional ideas. These are encapsulated in the attached project. I have also reproduced the main source file since this is where most of the action takes place.
This was, for me, an interesting digression into the area of IL generation using System.Reflection.Emit which is something I haven't done since my old Speech Server days.
Here's a summary of what I ended up doing:
- The multimethod factory generates a dynamic assembly on the fly. This assembly contains an automatically generated holder class encapsulating the delegate corresponding to each runtime overload of the multimethod plus a private invoker method for each overload. A central invoker method uses System.Type.InvokeMember to perform runtime method resolution while the private invokers perform marshalling and unmarshalling of arguments in and out of the runtime overload.
- This implementation supports by-reference arguments such as ref and out parameters along with in parameters as well as return values, so it offers something much closer to a complete solution than my initial implementation.
- The DebugInfo configuration class can be used to force the code generation phase to generate on-disc assemblies, symbols and pseudo-code which is provided to aid debugging of the generated IL: the code generation is somewhat fragile and it's very easy to leave the code generating "invalid program" errors when it gets JITted.
- The on-disc assemblies can also be referenced in other solutions in order to use the generated multimethod without the overhead of the code/assembly generation phase.
For future investigation:
- It would be nice to eliminate the reflection. As discussed at the recent PDC, there is a new planned dynamic pseudo-type in C# 4.0 which will allow for late-bound method calls. This is designed to improve COM interoperability but could just as well be applied to the problem of multiple dispatch. It would likely simplify a great deal of the IL that my multimethod factory has to generate.
- Currently, the delegate types used to construct the multimethod have to be declared public since the dynamic assembly that implements the multimethod holder needs to be able to access these types at runtime. I would like to be able to remove this limitation in order to improve encapsulation.
- I'm sure I could use abstract syntax trees and DLR-type on-the-fly code generation to do much of what can be done here. However, to remain compatible with .NET Framework 3.5 I'll be sticking with my reflection-based implementation for the time being!
Until next time…
I read a couple of interesting articles on the subject of multiple dispatch last night. The first, entitled Visitor Pattern Considered Useless, starts by describing the visitor design pattern with particular emphasis on how it can enable the definition of new operations on a hierarchy of types without having to modify the hierarchy's classes themselves. It gave a quick overview and then moved on to a critique of the pattern and segued into a description of the multimethod implementation provided by Nice which is a very interesting Java-like (and hence C#-like) object-oriented programming language. This got me thinking about playing around with the idea of multiple dispatch in C#. Check out the attachment containing a sample project I hacked together or view the main class here.
Note the following:
- Basically, it performs overload resolution of generic methods at runtime as opposed to C#'s usual overload resolution which is performed at compile time.
- It's based heavily around delegates.
- It determines the "most compatible" method based on a measure of "generality" of parameter types compared to actual argument types.
- Currently it only handles methods that take "in" parameters. It doesn't do "out" or "ref" and doesn't support return values yet.
- The code is not performant: currently all the runtime overload resolution is done through multiple "for" loops over the parameter and argument type arrays. I'm sure some DLR-type magic could be employed instead to improve the performance of this area of the code.
- This code is incredibly rough around the edges.
- It's a work in progress.
If there are any other dynamic programmers in C# interested in this kind of thing, then let me know!
Windows Installer APIs tamed in managed code: use this to dump out a list of all installed product codes and component IDs. Quick and easy. Good night everybody!
Firstly, it's election day so get out there and vote! Secondly, I went to bed last night and dreamt about functors! Last Friday I code-reviewed some changes made by one of my colleagues and his code just happened to use some STL containers and all sorts of related goodies. The last time I tried to use STL was about eight years ago when I was still at college and, admittedly, I didn't use them much: compiler support (both on Unix and Windows platforms) was not great and so I ended up using Matlab for most of my work instead.
Anyway, this got me thinking: wouldn't it be nice to be able to use the STL auto_ptr template to manage Windows handles in addition to regular old object pointers? Unfortunately, this was a no-go for two main reasons:
- The semantics are all wrong: auto_ptr<HANDLE>, where HANDLE is a generic Windows-style opaque pointer, doesn't work as the resulting auto_ptr specialization is semantically equivalent to HANDLE * (i.e. a pointer to a HANDLE). This is one level of pointer indirection too much to be useful for us.
- auto_ptr, unlike the TR1 shared_ptr, does not allow the developer to define a custom deleter function: auto_ptr always invokes the delete operator on the type of the encapsulated pointer. Windows handles typically use CloseHandle or something similar.
So, I began to write my own. First, I thought I'd steal some inspiration from the auto_ptr and shared_ptr classes. Unfortunately, this is not easy as it might sound. Anybody who has ever read the source code for STL would likely agree with me on this: the STL headers are not designed to be humanly readable as far as I can tell. Therefore I had to write it from scratch and reproduced below is my scoped_handle implementation:
Click to view source code for scoped_handle
Of course, I went through several iterations before I got it right. The first used a single encapsulated deleter function pointer. This suffered from the main issue that the deleter function had to conform to a very specific function prototype. Thus it becomes difficult to produce a generic class that can handle void (*)(HANDLE) functions and BOOL (*)(HANDLE) equally well (CloseHandle belonging to the latter category). After some head scratching I developed the implementation listed above based on the STL-style concept of functors. Specifically, this template class can handle any object, be it a function or class or anything else, as long as it supplies an overload of operator() that takes a single appropriately typed argument. This operator can return any type since scoped_handler ignores the return value anyway.
A few caveats become obvious:
- Beware compiler warning C4930 from Visual C++! This warning is the reason why I did not provide a constructor of the form explicit scoped_handle(CALLABLE_TYPE) which would have created a default, "empty" handle set to UNDEFINED_VALUE initialized with the specified deleter. The compiler cannot distinguish between a class instantation or function prototype in this type of code.
- This code throws C++-style exceptions. If you're using this class in COM code you must catch all C++ exceptions and translate them into equivalent HRESULTs or stack-unwinding chaos will ensue.
This is roughly how one might use the scoped_handle class in conjunction with common Windows APIs:
Click to view source code for example of usage
See you next time!
So, I did a whole lot more research and investigation of COM eventing in Office applications and how this compares to the "general" COM eventing case. Check out
IConnectionPoint and .NET or: How I Learned to Stop Worrying and Love Managed Event Sinks (part 1).
A few things occurred to me the other day while I was playing around with my COM connection point code and I realized that my article contains a number of errors. I intend to correct these some time and then I'll republish it as soon as possible. Please call back later!
My first article (
IConnectionPoint and .NET) is a multi-part discussion contrasting .NET delegate-style event handling with classic COM IConnectionPoint eventing from managed code. Excel is my choice of
victim application.
My name's Richard and I'm a developer in the
Visual Studio Tools for Office team at Microsoft.
