HttpListener is a pretty cool class hiding in the depths of the .NET Framework: as the name suggests, it provides an HTTP listener (the core of a mini web server) and can decode web requests sent to it. There's nothing special about these web requests - they can come from any application you want and, in fact, a web browser or the wget utility are quite useful when testing an application hosting this sort of service. And did I mention that it's very easy to use.

Here's how to create one and start listening:

this.listener = new HttpListener();
this.listener.Prefixes.Add(string.Format("http://localhost:17765/"));
this.listener.Start();
this.listener.BeginGetContext(ListenerCallback, null);

The "prefixes" are what addresses the listener pays attention to - the significant thing here is the port number, and just pick something that doesn't collide with other services. (Since I do in fact have IIS on my development PC, I want to avoid port 80.) The last line above starts the listener waiting for and processing an incoming request, the completion of which will occur in the ListenerCallback method. Note that this isn't registering a handler for any incoming message, but initiating processing of a single received message, i.e., you have to keep calling this to keep receiving messages.

Before talking about the callback, here's how to shut the thing down when you're done with it:

this.listener.Stop();
this.listener.Close();

The callback function is where everything happens, in this case, a trivial bit of code that reacts to /key?k=<something> requests (the beginning of a key injection application, if you must know):

private void ListenerCallback(IAsyncResult result)
{
    if (!this.listener.IsListening)
        return;
 
    try
    {
        var context = this.listener.EndGetContext(result);
        var request = context.Request;
        HttpStatusCode responseCode;
        if (!request.IsLocal)
            responseCode = HttpStatusCode.Forbidden;
        else
        {
            switch (request.Url.AbsolutePath)
            {
                case "/key":
                    var key = request.QueryString["k"];
                    if (key == null)
                        responseCode = HttpStatusCode.BadRequest;
                    else
                    {
                        Debug.Print("Received key " + key);
                        bool success = true;
                        responseCode = success ? HttpStatusCode.OK : HttpStatusCode.ServiceUnavailable;
                    }
                    break;
                default:
                    responseCode = HttpStatusCode.NotFound;
                    break;
            }
        }
        context.Response.StatusCode = (int)responseCode;
        context.Response.Close();
 
        // Wait for the next request
        this.listener.BeginGetContext(ListenerCallback, null);
    }
    catch(IOException)
    {
    }
}

Let's examine this in detail. First, a check that the listener is still active - when stopped, IsListening will be false. (Note that if the listener is torn down while the callback is running, an IO exception is thrown - I really ought to avoid this instead of wrapping the handler in a try...catch block.) Having determined that the listener is running, EndGetContext completes the reception of an HTTP request. Since, as I said above, I want to handle only communications within the PC, I reject any incoming requests where IsLocal is false (the HttpListener can be used across machines too, of course, though configuration is a bit of a chore).

Next, I "parse" the URL in the request, looking for path "/key" and the "k" query parameter. All I do here is print out the received message.

I close the request's response to let the client clean up correctly - there's just an error status and no content (though I could send something back - an HTML help page, for example, when given an unrecognised request URL).

Finally, as mentioned above, the callback is not registered as a continuous handler, but as the completion function for a single request, so I need to initiate another request-to-receive before returning.

That's all there is to a simple mini web server. To test it, run and then fire up a web browser and navigate to "http://localhost:17765/key?k=F" and the debug console will show the expected message.

Here's a mindtaxingly complex .NET client which does the same thing:

var req = WebRequest.CreateHttp("http://localhost:17765/key?k=F");
var resp = req.GetResponse();

I could examine the response for the error code (or any content passed back) but I lazily don't care here.

Since this was all so simple, here's the same thing in native C++:

auto inet = InternetOpen(L"MyAppClientId", INTERNET_OPEN_TYPE_PRECONFIG, nullptr, nullptr, 0);
auto conn = InternetOpenUrl(inet, L"http://localhost:17765/key?k=F", nullptr, 0, 0, 0);
InternetCloseHandle(conn);
InternetCloseHandle(inet);

I was brought up on raw sockets many years ago, and it still feels kinda astonishing that a web request can require so little C++.

So there you have it. Not as clever as .NET Remoting, in that you have to pack and unpack message arguments, but still very simple and quite performant.

There are three components in a typical remoting setup: a class definition for whatever it is I need to communicate between the two processes, a client library and a server mechanism at the other end.

The following is a (much simplified) version of the library I use to communicate between Project Colletta add-ins and the main process:

public interface IToolbarManager
{
    Guid CreateToolbar(IntPtr hwnd, string path, string title);

    [System.Runtime.Remoting.Messaging.OneWay]
    void Move(IntPtr hwnd, Guid docId);
}

The first method requests that the main process create a tool bar associated with the window (HWND) and document (path and title) specified. The second method is used for the add-in to notify the main process that the window has moved, and thus the tool bar needs to be moved too - this can be marked as OneWay, to gain a slight efficiency improvement, because the client doesn't need to wait for the server to do anything before it can move on (as also indicated by the method's void return). This is built into a separate assembly that can be shared between client and server.

The server provides a concrete implementation of this interface:

internal class ToolbarManager : MarshalByRefObject, IToolbarManager
{
    public Guid CreateToolbar(IntPtr hwnd, string path, string title)
    {
        // Create the tool bar
    }

    public void Move(IntPtr hwnd, Guid docId)
    {
        // Move the tool bar
    }
}

Note that it derives from MarshalByRefObject, a signal that this is exposed for remote access. The only other thing the server has to do is expose this to the outside world - there are several ways to do this, but I tend to use the following:

var provider = new BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
var props = new System.Collections.Hashtable();
props["port"] = SOME_PORT_NUMBER;
props["bindsTo"] = "localhost";
props["rejectRemoteRequests"] = "true";
ChannelServices.RegisterChannel(new System.Runtime.Remoting.Channels.Tcp.TcpServerChannel(props, provider), false);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(ToolbarManager), "SOME_UNIQUE_NAME", WellKnownObjectMode.Singleton);

Only the last pair of calls is actually essential since the system accepts defaults for most of the communication properties, but I tend to take the opportunity to define some non-default values. First, I explicitly request binary serialization (XML is an alternative). Second, by setting "rejectRemoteRequests" I ensure that only processes on the same machine can invoke functions on the server process. The last line means that any process asking for the IToolbarManager interface on the specified port will create or reuse an instance of the ToolbarManager concrete class - and that's all that is required on the server. Do note that requests can come in on arbitrary threads, and I usually end up having methods such as those in ToolbarManager marshal across to the main thread or provide some other means of thread synchronization.

On the client side, I make sure that the TCP channel is available:

ChannelServices.RegisterChannel(new System.Runtime.Remoting.Channels.Tcp.TcpClientChannel(), false);

and specify the connection with:

var manager = (IToolbarManager)Activator.GetObject(typeof(IToolbarManager),
                 "tcp://localhost:" + SOME_PORT_NUMBER + "/" + SOME_PORT_NAME);

Now I can invoke manager.CreateToolbar and manager.Move to perform those operations.

And that's all there is to it - it really is so simple that, even though this is deprecated technology, it's still my favourite way to get a couple of processes to talk to each other. If you want to know more about .NET Remoting, I can recommend a couple of really good books - you can tell from their publication dates (2005 and 2002, respectively) that this is old technology!

The basis of the trick is to get someone to think of a number from 1 to 8; you run a drawing app on the phone and doodle a prediction, then place the phone face down; ask the person for their prediction and you turn the phone face up to show the same number. The way it works is that the drawing app is much more than that: when the phone is rotated from face down to up, the direction and speed of rotation causes the app to choose one of 8 images to show. I do feel a bit guilty at giving away the secret of the magic trick but Greg and Brian Brushwood pretty much completely did that in the Scam School episode anyway!

The root of the app, as mentioned, is the accelerometer and the easiest way to see how it works is to grab the demo code from the MSDN samples site. If you run that app, you'll see that it reads X=0, Y=0, Z=1 when you hold the phone face down, as shown below:

Actually, you'll see values close to 1 and 0 - there will be some noise. If you tilt the phone along the long axis, you'll get X=1 (or -1 depending on which direction you tilt) and Y=0, Z=0, as shown below:

As you might expect, while transitioning from horizontal to vertical, Z will decrease and X (or Y, if tilting along the short axis) will get further from 0. All I need to do in this app is note which axis is increasing and in which direction as Z changes from close to 1 to a little bit from 0 - I want to make sure I've made my choice well before Z reaches 0, so that the victim can't see an incorrect screen. If you've been paying attention, you'll note that this gives only four values (positive X, positive Y and the two negatives): I also look at the speed of the transition - fast or slow - to give an additional four. Incidentally, I've no idea how the details here match up with iForce - I've not seen the source for that, nor have I looked any more closely at the app than what appeared in the video mentioned above. I've just thrown together something that kinda does the same job.

The accelerometer is started with:

this.accelerometer.CurrentValueChanged += Accelerometer_CurrentValueChanged;
this.accelerometer.Start();

The callback is where the, er, magic happens:

        void Accelerometer_CurrentValueChanged(object sender, SensorReadingEventArgs<AccelerometerReading> e)
        {
            this.accumulator = this.accumulator * 0.8f + e.SensorReading.Acceleration * 0.2f;
            if (accumulator.Z > 0.9f)
            {
                this.startToMove = DateTime.Now;
                this.started = true;
            }
            else if (accumulator.Z < 0.2f && this.started)
            {
                done = true;
                bool isLong = (DateTime.Now - this.startToMove).TotalSeconds > 1.0;
                var scores = new double[] { -accumulator.Y, accumulator.Y, accumulator.X, -accumulator.X };
                var best = 0;
                for (int i = 1; i < scores.Length; ++i)
                    if (scores[i] > scores[best])
                        best = i;
                if (isLong) best += 4;
                this.started = false;
                this.Dispatcher.BeginInvoke(() =>
                {
                    // SET DISPLAY TO <best>
                });
            }
        }

After applying a simple bit of smoothing to reduce the effect of noise, there are two phases: if the Z value is close to 1, assume the phone is face down and store the current time (as startToMove); if the Z value is close-ish to 0, work out which of the 4 directions of rotation happened, simply by looking for the maximum magnitude of the X and Y readings, and look at the time taken to get from face down to almost vertical. While I could pre-can 8 images and select one at the end of that callback, the rest of this short application deals with collecting 8 doodles from the user and persisting them across runs of the application.

The obvious mechanism to use is the InkPresenter. I capture "mouse" down (i.e., finger touching the screen) and moves to capture drawing actions, and then convert those to stroke data to store on the ink presenter:

private void Ink_MouseLeftButtonDown(object sender, System.Windows.Input.MouseButtonEventArgs e)
{
    this.Ink.CaptureMouse();
 
    this.stroke = new Stroke();
    this.stroke.StylusPoints.Add(e.StylusDevice.GetStylusPoints(this.Ink));
    this.stroke.DrawingAttributes.Color = System.Windows.Media.Colors.White;
    this.stroke.DrawingAttributes.Width = 3.0;
    this.Ink.Strokes.Add(this.stroke);
}
 
private void Ink_MouseMove(object sender, System.Windows.Input.MouseEventArgs e)
{
    if (this.stroke != null)
        this.stroke.StylusPoints.Add(e.StylusDevice.GetStylusPoints(this.Ink));
}
 
private void Ink_MouseLeftButtonUp(object sender, System.Windows.Input.MouseButtonEventArgs e)
{
    this.stroke = null;
    this.Ink.ReleaseMouseCapture();
}

(Ink is the InkPresenter, stroke is a Stroke object which is added to the StrokeCollection rendered on the presenter.)

The app has an edit page which iterates over 8 drawings, thus giving me a collection of the 8 stroke collections to be displayed. The final lines of the accelerometer change routine above select the appropriate set of strokes and loads them into the ink presenter.

The final bit of polish on the app is to persist the stroke data, instead of requiring the user to do the 8 drawings every time. Alas the stroke collection class is not itself serializable, so I need to convert to some string format to persist in phone storage. Being lazy, I let the XmlSerializer handle the final conversion, and just convert the 8 stroke collections into a multi dimensional array of points (an array of stroke collections, each of which is an array of strokes, each of which is an array of points - I'm ignoring stroke attributes such as colour and thickness here).

        internal void Save()
        {
            var pts = new Point[this.strokes.Length][][];
            for (int i = 0; i < this.strokes.Length; ++i)
            {
                var sc = this.strokes[i];
                pts[i] = new Point[sc.Count][];
                for (int j = 0; j < sc.Count; ++j)
                    pts[i][j] = sc[j].StylusPoints.Select(p => new Point(p.X, p.Y)).ToArray();
            }
            var ser = new XmlSerializer(pts.GetType());
            using (var s = IsolatedStorageFile.GetUserStoreForApplication().CreateFile("Strokes"))
            {
                ser.Serialize(s, pts);
            }
        }

        internal void Load()
        {
            try
            {
                using (var s = IsolatedStorageFile.GetUserStoreForApplication().OpenFile("Strokes", FileMode.Open))
                {
                    var ser = new XmlSerializer(typeof(Point[][][]));
                    var pts = (Point[][][])ser.Deserialize(s);
                    this.strokes = new StrokeCollection[pts.GetLength(0)];
                    for(int i = 0; i < strokes.Length; ++i)
                    {
                        var sc = new StrokeCollection();
                        foreach(var s in pts[i])
                        {
                           var stroke = new Stroke();
                            stroke.DrawingAttributes.Color = System.Windows.Media.Colors.White;
                            stroke.DrawingAttributes.Width = 3.0;
                            foreach (var p in s)
                                stroke.StylusPoints.Add(new StylusPoint(p.X, p.Y));
                            sc.Add(stroke);
                        }
                        this.strokes[i] = sc;
                    }
                }

            }
            catch
            {
                this.strokes = new StrokeCollection[8];
                for (int i = 0; i < 8; ++i)
                    this.strokes[i] = new StrokeCollection();
            }
        }

If loading fails (as it will the first time the app is run, for example), an empty set of stroke data is created.

So there you have it - a very poor sibling to Greg's iForce, but functional. (I'll put it in the store soon, and will update this article with a pointer.)

For the first step, I use Windows Events (see SetWinEventHook for details) to get a callback when windows are created or come to the foreground or move, etc. Only the first of those is really relevant to the current discussion, but I track movement to update the location of the docbars at the bottom of the document windows. (The docbars are implemented as separate windows, owned by the main Project Colletta application, positioned to line up with the related application window - if you drag application windows around very quickly, you can detect a lag before the docbar catches up - but that is a small price to pay compared to the complexity in incorporating the docbar code into each and every supported application process!) Here's a stripped down code fragment showing the basics.

[DllImport("user32.dll", SetLastError=true)]
internal extern static IntPtr SetWinEventHook( uint eventMin, uint eventMax, IntPtr hmodWinEventProc, WinEventProc lpfnWinEventProc, uint idProcess, uint idThread, uint dwFlags );

private Win32.WinEventProc winEventProc; // Keep as class member to prevent premature GC

private void WinEventHandler(IntPtr hWinEventHook, uint eventType, IntPtr hwnd, int idObject, int idChild, uint dwEventThread, uint dwmsEventTime)

{
    // Only look at top level windows
    if (idObject != OBJID_WINDOW || idChild != CHILDID_SELF || Win32.GetParent(hwnd) != IntPtr.Zero)
        return;

    switch (eventType)
    {
        case EVENT_OBJECT_CREATE:
            RegisterWindow(hwnd);
            break;

        ...
    }
}

...

    this.winEventProc = this.WinEventHandler;
    this.winEventHook = Win32.SetWinEventHook(EVENT_First, EVENT_Last, IntPtr.Zero,
                                               this.winEventProc, 0, 0,
                                               2 /*WINEVENT_OUTOFCONTEXT|WINEVENT_SKIPOWNPROCESS*/ );

...

When I have a new window to examine, I need to determine if it's one I'm interested in. I could look at its process name but that's a bit cumbersome and, since I need to look at its window class anyway, I can use that. A tool like Spy++ can show you the complete window hierarchy of a running application, something we'll look at in a moment, but all I need now is the class name for the top level window. GetClassName shows us that Word's main window is of class "OpusApp," Excel is "XLMAIN," PowerPoint is "PPTFrameClass" and Acrobat Reader is "AcrobatSDIWindow" - now these are not documented and guaranteed, so I do need to check them every time a new version of the application turns up.

The documentation for AccessibleObjectFromWindow has a table at the end showing what type of object we can get from a number of application's windoww - for example, a reference to a Microsoft.Office.Interop.Word.Window can be extracted from a window of class "_WwG" - but, hang on, we've got an "OpusApp" window, not a "_WwG" - what gives? This really is where Spy++ comes into its own: you can start at the "OpusApp" window and expand all the child windows until you find a "_WwG" a couple of levels down: one of the children of the top level window is of class "_WwF" which has one child of class "_WwB" and amongst the children of that is a single "_WwG" - it is fortunate that there only one child of the required type at each level since that makes the window search very easy. Again, this is undocumented and can change between versions (and in fact, has changed for PowerPoint - the chain for PowerPoint 2013 is "PPTFrameClass" "MDIClient" "mdiClass" but is "PPTFrameClass" "MDIClient" "mdiClass" "paneClassDC" for PowerPoint 2010, and something else again for PowerPoint 2007).

Given that, once the code above detects a top level window and I confirm it is of class "OpusApp" I can run the following to get hold of the Word object model Document displayed in it:

private Word.Document GetWordDocument(IntPtr hwnd)
{
    string[] classes = new string[] { "_WwF", "_WwB", "_WwG" };
    var docHwnd = SetDocumentWindowByClass(hwnd, classes);
    if (docHwnd != IntPtr.Zero)
    {
        object o = GetDocumentObject(docHwnd, typeof(Word.Window));
        var window = o as Word.Window;
        if (window != null)
            return window.Document;
    }

    return null;
}

private static IntPtr GetDocumentWindowByClass(IntPtr topHwnd, string[] classes)
{
        IntPtr docHwnd = topHwnd;
        for (int i = 0; i < classes.Length && docHwnd != IntPtr.Zero; ++i)
            docHwnd = Win32.FindWindowEx(docHwnd, IntPtr.Zero, classes[i], null);
        return docHwnd;
}

private static GetDocumentObject(IntPtr docHwnd, Type documentObjectType)
{
    Guid guid = documentObjectType.GUID;
    object o;
    if (AccessibleObjectFromWindow(docHwnd, OBJID_NATIVEOM, ref guid, out o) != 0)
        o = null;
    return o;
}
 
[DllImport("oleacc.dll")]
private static extern int AccessibleObjectFromWindow(IntPtr hwnd, uint id, ref Guid iid, [MarshalAs(UnmanagedType.IDispatch)] out object ppv);
private const uint OBJID_NATIVEOM = 0xFFFFFFF0;

A bit of web spelunking and playing with Spy++ showed a pleasant surprise with Acrobat Reader. It exposes a (rather limited) document model too. Underneath top level window of class "AcrobatSDIWindow" can be found a chain of  "AVSplitterView", "AVSplitationPageView", "AVSplitterView", "AVScrolledPageView", "AVScrollView", "AVPageView" (earlier versions of Acrobat Reader have different window hierarchies) and from the last of those we can get an IPDDomDocument, defined in the AcrobatAccessLib COM library (which you can easily get hold of via Add Reference, COM libraries), and this exposes a path value. Unfortunately, in protected mode (which is the default in later versions of the Acrobat Reader), the path is to a temporary copy rather than to the file the user opened, so it's not so useful after all.

So, to conclude, VSTO gives you a good insider view of an application, and AccessibleObjectFromWindow can link that to the outsider view, so that you can make something associated with the window on the screen react to the contents of the document shown in that window.

internal class Program
{
    [STAThread()]
    public static void Main()
    {
        string name = new AssemblyName(Assembly.GetExecutingAssembly().FullName).Name;
        bool mutexCreated;
        using (var mutex = new Mutex(false, name, out mutexCreated))
        {
            if (mutexCreated)
            {
                WerExclusion(true);

                App.Main();

                WerExclusion(false);
            }
            else
                MessageBox.Show("This app already running");
        }
    }
}

I create a mutex to be able to make sure only one copy of the application is running at a time - quite useful when debugging, in case I don't notice that a copy is already running and grabbing some shared resource. The assembly name is a convenient vaguely unique name for me to use, but I do sometimes make use of an explicit name, for example, when I have multiple co-operating processes, and I want one to be able to check if another is running. (I use this in Project Colletta for application add-ins to check if the main executable is running, to avoid messaging timeouts and errors.)

Unless you're a programming demigod, the first few versions of your application probably crash every so often. And this typically results in that dialog box asking you if you want to report errors to Microsoft, which is fairly pointless for a self-developed application, certainly in its early days. Since Windows Vista, a couple of functions have been available to mark (and unmark) applications as being excluded from this automatic error reporting - see the WerAddExcludedApplication documentation for details. I tend to mark my applications in this way, if nothing else, to remove the delay before I can dismiss the crash dialog and close the faulting application. For tidiness, though I don't think it's necessary, I get rid of the entry in the exclusion list when my app exits (ideally this should be later than shown here, but this suffices). The following is a simple wrapper on this native mechanism:

private static void WerExclusion(bool add)
{
    var exe = Assembly.GetExecutingAssembly().Location;
    try
    {
        int hr = add ? Win32.WerAddExcludedApplication(exe, false) :
                       Win32.WerRemoveExcludedApplication(exe, false);
        Debug.Assert(hr == 0);
    }
    catch
    {
        Debug.WriteLine("WER functions not available");
    }
}

[DllImport("wer.dll", CharSet=CharSet.Unicode)]
internal static extern int WerAddExcludedApplication(string exeName, [MarshalAs(UnmanagedType.Bool)] bool allUsers);

[DllImport("wer.dll", CharSet=CharSet.Unicode)]
internal static extern int WerRemoveExcludedApplication(string exeName, [MarshalAs(UnmanagedType.Bool)] bool allUsers);

(Yes, I know, I'm being far too sloppy in terms of error handling here - my feeble excuse is that this is a mere nice-to-have and not essential.)

Of course, an alternative to the Windows error report exclusion list manipulations would be to implement an unhandled exception handler (AppDomain.UnhandledException) but I tend not to do that for a couple of reasons: first, it needs to be done for each application domain and I often forget; second, it interferes (though only slightly) with debugging, in that by default Visual Studio traps unhandled exceptions itself, unless there's an handler for them (an easy default to change via the exception settings page). I'm in two minds about whether "proper" production applications should have unhandled exception handlers - yes, it's rather unprofessional to show your end users a crash dialog box, but then so is crashing in the first place... Besides, there's not really a huge amount such a handler can do apart from perhaps log some small amount of data and then exit the application.

Finally, deep within my Program.Main is a call to App.Main. In Windows Forms applications, the Visual Studio Wizard provides a Program class with a Main method, and I add my extras to that, around the call to Application.Run. In WPF applications, the normal entry point is App.Main, which is autogenerated by the build process. An executable can have as many Main methods as you want, but you do need to tell Windows which one is the real entry point - and that's pretty easy to do via the Application page of the project options - the Startup object dropdown lists all available entry points and I make sure I pick mine. App.Main can, of course, just be called like any other function too.

And that's it, my one and only application startup. Well, for desktop .NET applications anyway.

Now, there are examples of native add-ins for Outlook out there - here are a couple of articles worth reading  - the examples I've come across have, like these, used ATL. I find that ATL is very useful for creating COM objects of any complexity but feel that it's overkill for simple COM objects that have no Windows UI of their own: I don't like dragging in extra code to initialise things I don't need and it is a pain trying to debug through layers of wrappers (wrappers that were very convenient when writing the code, it must be said). Years ago, I user to work with DirectShow, and the COM framework that appeared in associated samples used was much simpler than ATL - through reading those and some of the shell integration samples, I've ended up writing a lot of COM material without using any support framework.

Given all that, there are two parts to the add-in: "boilerplate" COM registration, and talking to Outlook. A very good summary of the first can be found in Raymond Chen's blog and I won't repeat it here but will focus on the second. My Outlook add-in needs to implement three COM interfaces: IDTExtensibility2 (for an Office application to be able to load it), IRibbonExtensibility (as the name suggests, to be able to interact with the ribbon), and IDispatch (to handle ribbon callbacks); and the first of those is pretty straightforward:

	STDMETHOD(OnConnection)(LPDISPATCH /*application*/, AddinDesign::ext_ConnectMode /*connectMode*/, LPDISPATCH /*addInInst*/, SAFEARRAY** /*custom*/)
	{
		return S_OK;
	}
	STDMETHOD(OnDisconnection)(AddinDesign::ext_DisconnectMode /*removeMode*/, SAFEARRAY** /*custom*/)
	{
		return S_OK;
	}
	STDMETHOD(OnAddInsUpdate)(SAFEARRAY** /*custom*/)
	{
		return S_OK;
	}
	STDMETHOD(OnStartupComplete)(SAFEARRAY** /*custom*/)
	{
		return S_OK;
	}
	STDMETHOD(OnBeginShutdown)(SAFEARRAY** /*custom*/)
	{
		return S_OK;
	}

In my case, no need to do anything in response to the extensibility callbacks apart from to say, yup, OK, continue on your way. IRibbonExtensibility has only one methid, GetCustomUI, which is pretty much the same as the managed one I've shown before - the details are slightly different, this being C++, so it's not as convenient as simply returning a string:

STDMETHODIMP CNoReplyAllLite::GetCustomUI(BSTR ribbonID, BSTR* ribbonXml)

{
	wchar_t* xml;
	if (     lstrcmpW(ribbonID, L"Microsoft.Outlook.Mail.Compose") == 0 ||
		     lstrcmpW(ribbonID, L"Microsoft.Outlook.MeetingRequest.Send") == 0 ||
		     lstrcmpW(ribbonID, L"Microsoft.Outlook.Post.Compose") == 0)
		xml = composeRobbomXml
L"<?xml version='1.0' encoding='UTF-8'?>"
L"<customUI xmlns='http://schemas.microsoft.com/office/2006/01/customui' loadImage='Ribbon_LoadImage'>"
L" <ribbon>"
L"  <tabs>"
L"   <tab idMso='TabNewMailMessage'>"
L"    <group id='grpCReply' label='Disable'>"
L"     <toggleButton id='btnCNoReplyAll' tag='2'"
L"                   size='large' image='2'"
L"                   getPressed='ItemButton_IsPressed' onAction='ItemButton_Click'"
L"                   screentip='No Reply All' supertip='Prevent recipients within the same organisation from replying to all'"
L"                   label='Reply All' />"
L"     <toggleButton id='btnCNoReply' tag='1'"
L"                   size='normal' image='1'"
L"                   getPressed='ItemButton_IsPressed' onAction='ItemButton_Click'"
L"                   screentip='No Reply' supertip='Prevent recipients within the same organisation from replying'"
L"                   label='Reply' />"
L"     <toggleButton id='btnCNoForward' tag='3'"
L"                   size='normal' image='3'"
L"                   getPressed='ItemButton_IsPressed' onAction='ItemButton_Click'"
L"                   screentip='No Forward' supertip='Prevent recipients within the same organisation from forwarding the message'"
L"                   label='Forward' />"
L"    </group>"
L"   </tab>"
L"  </tabs>"
L" </ribbon>"
L"</customUI>";
	else
		xml = nullptr;

	*ribbonXml = xml ? SysAllocString(xml) : nullptr;
	return S_OK;
}

My IDispatch implementation takes care of matching the callbacks in that, such as ItemButton_IsPressed, to a C++ method:

STDMETHODIMP CNoReplyAllLite::GetIDsOfNames( REFIID, OLECHAR** names, UINT num, LCID lcid, DISPID* dispids )

{
	HRESULT hr = S_OK;
	for( UINT i = 0; i < num; ++i )
		if( CompareStringW( lcid, 0, names[ i ], -1, L"ItemButton_Click", -1 ) == CSTR_EQUAL )
			dispids[i] = DISPID_ITEMBUTTON_ONACTION;
		else if( CompareStringW( lcid, 0, names[ i ], -1, L"ItemButton_IsPressed", -1 ) == CSTR_EQUAL )
			dispids[i] = DISPID_ITEMBUTTON_GETPRESSED;
		else if( CompareStringW( lcid, 0, names[ i ], -1, L"Ribbon_LoadImage", -1 ) == CSTR_EQUAL )
			dispids[i] = DISPID_RIBBON_LOADIMAGE;
		else
		{
			dispids[i] = DISPID_UNKNOWN;
			hr = DISP_E_UNKNOWNNAME;
		}
	return hr;
}

STDMETHODIMP CNoReplyAllLite::Invoke( DISPID dispid, REFIID, LCID, WORD /*flags*/, DISPPARAMS* params, VARIANT* result, EXCEPINFO*, UINT* )
{
	switch( dispid )
	{
		case DISPID_ITEMBUTTON_ONACTION:
			{
				// Remember: rgvarg array in *reverse* order
				Office::IRibbonControlPtr control = params->rgvarg[1].pdispVal;
				ItemButton_Click(control, params->rgvarg[0].boolVal);
			}
			break;

		case DISPID_ITEMBUTTON_GETPRESSED:
			{
				Office::IRibbonControlPtr control = params->rgvarg[0].pdispVal;
				variant_t b = ItemButton_IsPressed(control);
				*result = b.Detach();
			}
			break;

		case DISPID_RIBBON_LOADIMAGE:
			{
				IDispatchPtr pic = Ribbon_LoadImage(params->rgvarg[0].bstrVal);
				variant_t disp = pic.Detach();
				*result = disp.Detach();
			}
			break;
	}

	return S_OK;
}

Notice that rather than "raw" VARIANTs and COM pointers, I favour variant_t and the _com_ptr_t types: these wrap and hide the details of cleanup and, in the case of the latter, QueryInterface too. (Without these, I'd almost certainly make more use of ATL, because it provides similar wrappers.)

Taking a small step back: in order to be able to access the extensibility and Office interfaces, I need to import their type libraries, which requires the following -

// IDTExtensibility2
#import "libid:AC0714F2-3D04-11D1-AE7D-00A0C90F26F4" auto_rename auto_search raw_interfaces_only rename_namespace("AddinDesign")

// Office type library (i.e. mso.dll)
#import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52" auto_rename auto_search raw_interfaces_only rename_namespace("Office")

// Outlook type library (i.e. msoutl.olb)
#import "libid:00062FFF-0000-0000-C000-000000000046" auto_rename auto_search rename_namespace("Outlook") rename("GetOrganizer", "GetOrganizerAddressEntry")

There are two ways to #import a library - by filename or by registered library id. The latter is more useful in that it doesn't require a fixed absolute path (which will change for different versions of Office, or non default installations). Unfortunately, using the libid versions confuses IntelliSense, and the Visual Studio editor doesn't recognise any of the type names, but that is only a problem in that erroneous red squigglies appear. #import can also make use of the helper classes mentioned above, but that's only useful when calling into the library as opposed to implementing interfaces defined there - here, that means that raw makes sense for the Office and extensibility libraries. The "cooked" definitions are useful for the Outlook object model library, but notice the rename at the end - without that the imported file ends up with two instances of GetOrganizer which differ only in return type, a C++ error.

Here are the handlers for the click and is-pressed callbacks (error checking omitted for brevity):

void CNoReplyAllLite::ItemButton_Click(Office::IRibbonControl* control, VARIANT_BOOL pressed)
{
	IDispatchPtr item = GetItemFromButton(control);
	Outlook::ActionPtr action = GetActionFromButton(control, item);
	VARIANT_BOOL enabled = pressed ? VARIANT_FALSE : VARIANT_TRUE;
	HRESULT hr = action->put_Enabled(enabled);
}

VARIANT_BOOL CNoReplyAllLite::ItemButton_IsPressed(Office::IRibbonControl* control)
{
	IDispatchPtr item = GetItemFromButton(control);
	Outlook::ActionPtr action = GetActionFromButton(control, item);
	VARIANT_BOOL enabled;
	HRESULT hr = action->get_Enabled(&enabled);
	return (SUCCEEDED(hr) && enabled) ? VARIANT_FALSE : VARIANT_TRUE;
}

There are definitely too many forms of boolean in Windows C++ - bool, BOOL and VARIANT_BOOL, all of which are different base types and have different values for true, hence the (perhaps overly pedantic) conversions between bool and VARIANT_BOOL above.

As with the VSTO implementation, I follow a short route from the ribbon control to get hold of the item it's associated with:

static IDispatchPtr GetItemFromButton(Office::IRibbonControl* control)
{
	HRESULT hr;
	IDispatchPtr context;
	hr = control->get_Context(&context);
	Outlook::_InspectorPtr inspector = context;
	IDispatchPtr item;
	hr = inspector->get_CurrentItem(&item);
	return item;
}

This is where things get a bit tricky... As mentioned before, the various Outlook items which appear in inspector windows do not share a common base class. I don't want to try QueryInterface for all of them, and then use almost identical code (but for the type) to access the Action associated with each. In the managed case, I used reflection instead and, here, I do more or less the same, via the item's IDispatch interface:

static Outlook::ActionPtr GetActionFromButton(Office::IRibbonControl* control, IDispatch* item)
{
	HRESULT hr;
	BSTR bstr = nullptr;
	hr = control->get_Tag(&bstr);
	_bstr_t tag(bstr, false);
	int index = bstr[0] - L'0';
	wchar_t* actionsName = L"Actions";
	DISPID id;
	hr = disp->GetIDsOfNames(IID_NULL, &actionsName, 1, LOCALE_SYSTEM_DEFAULT, &id);
	if (FAILED(hr))
		return nullptr;
	DISPPARAMS params = {0};
	variant_t result;
	hr = disp->Invoke(id, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYGET, &params, &result, nullptr, nullptr);
	Outlook::ActionsPtr actions = result;
	Outlook::ActionPtr action;
	variant_t actionIndex = index;
	hr = actions->Item(actionIndex, &action);
	return action;
}

Quite a lot uglier than the C# code I've shown before, but it's doing the same thing.

The final task for the code is button images. Again, the C++ world is similar to the C# one, just a few more hoops to jump through. I've embedded icons for the three buttons, with resource ids 101-103, and the ribbon's loadImage callback grabs the resource and converts to an IPictureDisp to be displayed - although OleCreatePictureIndirect does indeed create one of those, I only actually need the IDispatch pointer here.

IDispatchPtr CNoReplyAllLite::Ribbon_LoadImage(BSTR imageName)
{
	int resourceId = 100 + imageName[0] - L'0';

	PICTDESC desc = {sizeof(PICTDESC)};
	desc.picType = PICTYPE_ICON;
	desc.icon.hicon = LoadIcon(g_hInst, MAKEINTRESOURCE(resourceId));
	assert(desc.icon.hicon);

	IDispatchPtr pic;
	HRESULT hr = OleCreatePictureIndirect(&desc, __uuidof(IDispatch), TRUE, (void**)&pic);

	DestroyIcon(desc.icon.hicon);

	return pic;
}

With all that in place, I have a native NoReplyAll implementation. It was more work than the VSTO one, up until the time I realised I had COM object locking problems in the managed version, which then became more complex and messier! Would I write any future add-ins in C++ or C#? I guess it depends: for something as teeny as this, especially if I wanted it to work across multiple Office applications, then native C++ could be a good idea. However, for anything of any complexity, the convenience of managed code really wins. One other benefit of the managed route is that the same assembly can be used in 32 and 64 bit Office: with native code, I do need to build separate DLLs for each.

And the final question is: is anyone sufficiently interested in this that I ought to make it a release alongside the managed download?

First of all, I need to adapt the program from last time so that it operates in two modes: as a resident application, as before, and a single shot "capture URLs and exit" mode. (There are other ways to support invoking from an external source such as the browser, but this is definitely the simplest.) I've replaced last time's Main with:

[STAThread]
static void Main()
{
    var args = Environment.GetCommandLineArgs();
    if (args.Length > 1)
        switch (args[1][0]) // Just look at first letter and ignore the rest
        {
            case 'c':
            case 'C':
                CopyInternetExplorerTabsToClipboard();
                break;
        }
    else
    {
        bool mutexCreated;
        using (var mutex = new Mutex(false, "BrowserClip.Started", out mutexCreated))
        {
            if (mutexCreated)
            {
                <Body of the previous version>
            }
            else
                MessageBox.Show("The URL clipper is already running");
        }
    }
}

The first modification is to check for command line arguments: if something starting with an upper or lowercase 'c' is given, perform the URL clip immediately, otherwise run as before. The second is a small bit of tidiness, to ensure that at most only a single resident instance of the application is running at any given time: the way this works is for the program to attempt to create a kernel object, a Mutex in this case; if this succeeds, then this is the first instance of the program, whereas if the Mutex already exists, another copy is already running.

Adding something to IE's context menu is a two stage operation: a bit of registry manipulation to install the menu item and, because that can point only to an HTML file, such a file to invoke the clipping application. According to the MSDN page, you add the following to the registry to define a context menu item:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt\Clip all URLs]
"Contexts"=dword:00000001
@="<SOMEPATH>\RunBrowserClip.htm"

I.e., add a key under HKCR\Software\Microsoft\Internet Explorer\MenuExt with the name of the menu item, giving its default value the absolute path to the HTML file to "run." The context defines when the menu item appears, 1 being the default - see the MSDN page for more details.

The HTML file contains nothing more than some JavaScript to run the application (with 'c' as the argument):

<html>
<script type="text/javascript">
var shell = new ActiveXObject("WScript.Shell");
shell.Run('"<EXEPATH>\\BrowserClip.exe" c');
</script>
</html>

Again, this has to specify a complete path, to the executable this time, but note that backslashes have to be escaped here (i.e., doubled) or could be switched to forward slashes.

With this in place, you should now see "Clip all URLs" on IE's right click menu, and selecting that will place all URLs on the clipboard, just the same as using the Notification Area icon or hotkey. (The first time you use it from the context menu, you'll get a warning that the web page wants to execute something, but you can suppress that warning thereafter.)

It is slightly annoying that full paths are needed in both the registry and the HTML file: a nice setup program could insert the correct paths at install time but that seems like a lot of work. Instead, I chose to add registration operations to the program. The argument switch statement is augmented with 'r' to register and 'u' to unregister:

    case 'r':
    case 'R':
        RegisterContextMenu();
        break;
    case 'u':
    case 'U':
        UnregisterContextMenu();
        break;

And the functions look like this:

private const string regPath = @"Software\Microsoft\Internet Explorer\MenuExt\Clip all URLs";

private static void RegisterContextMenu()
{
    var exePath = Assembly.GetExecutingAssembly().Location;
    var directory = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
    var htmlPath = GetHtmlPath();
    using (var w = new StreamWriter(htmlPath))
    {
        w.WriteLine("<html><script type='text/javascript'>");
        w.WriteLine("var shell = new ActiveXObject('WScript.Shell');");
        w.WriteLine("shell.Run('\"{0}\" c');", new Uri(exePath).AbsoluteUri);
        w.WriteLine("</script></html>");
    }
    using (var key = Registry.CurrentUser.CreateSubKey(regPath))
    {
        key.SetValue(null, htmlPath, RegistryValueKind.String);
        key.SetValue("Contexts", 1, RegistryValueKind.DWord);
    }
}

private static void UnregisterContextMenu()
{
    Registry.CurrentUser.DeleteSubKeyTree(regPath);
    var htmlPath = GetHtmlPath();
    File.Delete(htmlPath);
}

private static string GetHtmlPath()
{
    var directory = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
    return Path.Combine(directory, "RunBrowserClip.htm");
}

I write the HTML file into the current user's LocalAppData space (somewhere I can write without requiring admin permissions), and the contents of both the registry value and that HTML file are built on the fly to point to the appropriate places. Unregistering simply removes both parts again.

The first part of the puzzle is to find all the browser windows (tabs, actually) - I'm going to restrict myself to Internet Explorer because there's a convenient mechanism for locating them all (and, beside, given who I work for, it's obvious where I'm going to start), IShellWindows, if I get hold of an appropriate object exposing that interface, I can iterate over the collection, identifying which windows are actually browser windows (the collection includes Windows Explorer as well as Internet Explorer), and grab their URLs:

        private static IEnumerable<Tuple<string, string>> GetAllInternetExplorerTabs()
        {
            var tabs = new List<Tuple<string, string>>();

            var CLSID_ShellWindows = new Guid("9BA05972-F6A8-11CF-A442-00A0C90A8F39");
            var shellWindowsType = Type.GetTypeFromCLSID(CLSID_ShellWindows);
            dynamic shellWindows = Activator.CreateInstance(shellWindowsType);

            int count = shellWindows.Count;
            for (int i = 0; i < count; i++)
            {
                try
                {
                    var browser = shellWindows.Item[i];
                    if (browser != null)
                    {
                        if (GetClassName((IntPtr)browser.HWND) == "IEFrame")
                        {
                            string url = browser.LocationURL;
                            string title = browser.LocationName;
                            Marshal.ReleaseComObject(browser);
                            tabs.Add(new Tuple<string, string>(url, title));
                        }
                    }
                }
                catch
                {
                }
            }
            Marshal.ReleaseComObject(shellWindows);
            return tabs;
        }

Ignoring the fact that I'm being embarrassingly cavalier with regard to exception handling here, this operates by grabbing a ShellWindows object and extracting the URL and title from found browser windows. I've managed to keep the code very short by (lazily) relying on "dynamic" to look up properties and methods instead of COM casting things to the correct types. There will be a performance cost, but it's not important for this trivial application. If any of the dynamic accesses fail, an exception is thrown, hence my try...catch. I identify IE windows by looking at their window class names, using the helper function below. Finally, this routine returns a list of URL and title pairs for further processing.

        private static string GetClassName(IntPtr hwnd)
        {
            var sb = new StringBuilder(256);
            GetClassName(hwnd, sb, sb.Capacity);
            return sb.ToString();
        }

        [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
        private static extern int GetClassName(IntPtr hwnd, StringBuilder lpString, int nMaxCount);

.NET offers a very easy way to place matter on the clipboard, Clipboard.SetText, and I use it as follows:

        private static void CopyInternetExplorerTabsToClipboard()
        {
            var sb = new StringBuilder();
            foreach (var t in GetAllInternetExplorerTabs())
            {
                if (Properties.Settings.Default.IncludeTitles)
                    sb.AppendLine(t.Item2);
                sb.AppendLine(t.Item1);
            }

            if (sb.Length > 0)
                Clipboard.SetText(sb.ToString());
        }

I found I needed that length check because Clipboard.SetText got unhappy when given no text.

The next step is to wrap this in an application - I created a Windows Forms app, and threw away the form, creating a Notification Area icon instead:

        private static NotifyIcon CreateNotificationIcon()
        {
            var menu = new ContextMenu(
                new MenuItem[]{
                    new MenuItem("Clip URLs", (sender, e) => { CopyInternetExplorerTabsToClipboard(); }),
                    new MenuItem("Include titles", (sender, e) =>
                                                {
                                                    var mi = (MenuItem)sender;
                                                    Properties.Settings.Default.IncludeTitles = !mi.Checked;
                                                    Properties.Settings.Default.Save();
                                                    mi.Checked = Properties.Settings.Default.IncludeTitles;
                                                }){ Checked = Properties.Settings.Default.IncludeTitles },
                    new MenuItem("-"),
                    new MenuItem("Exit", (sender, ee) => { Application.Exit(); })
                });
            var notify = new NotifyIcon
            {
                Icon = Icon.ExtractAssociatedIcon(Assembly.GetExecutingAssembly().Location),
                ContextMenu = menu,
                Text = "Browser URL clipper",
                Visible = true
            };
            notify.Click += (sender, e) => { CopyInternetExplorerTabsToClipboard(); };

            return notify;
        }

Note that I added a boolean property, IncludeTitles, to the project settings to preserve the user's choice of whether to, er, include titles in the clipped text or not. A left click on the icon will clip all URLs, a right click pops up a menu which offers control of that property, and an application exit option.

Now, it is a bit of a chore to have to move the mouse pointer all the way to the Notification Area, so I added a basic hotkey handler too. This would have been easier if my application had a main window, but it's only slightly more effort without - I need to install a message filter, which gets a chance to peek at all messages sent to the main thread, and traps my hotkey message:

        private const int HotkeyId = 1196; // Totally arbitrary

        private class MessageFilter : IMessageFilter
        {
            public bool PreFilterMessage(ref Message m)
            {
                if (m.Msg == 0x0312 /* WM_HOTKEY */ && m.WParam.ToInt32() == HotkeyId)
                {
                    CopyInternetExplorerTabsToClipboard();
                    return true;
                }
                return false;
            }
        }

With all that in place, all that remains is to register the hotkey, create the notification icon, install the message filter, and run the message pump. When the user exits the application, undo all of that too:

        [STAThread]
        static void Main()
        {
            RegisterHotKey(IntPtr.Zero, HotkeyId, 6 /* Ctrl + Shift */, 'C');
            var notify = CreateNotificationIcon();
            var filter = new MessageFilter();
            Application.AddMessageFilter(filter);

            Application.Run();

            Application.RemoveMessageFilter(filter);
            notify.Dispose();
            UnregisterHotKey(IntPtr.Zero, HotkeyId);
        }

        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool RegisterHotKey(IntPtr hwnd, int id, int modifiers, uint vk);

        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static extern bool UnregisterHotKey(IntPtr hwnd, int id);

I've arbitrarily chosen Ctrl+Shift+C to snapshot URLs - if I wanted to be less lazy, I'd include a configuration option for this, but I'll leave it as an exercise for the reader.

That's it: about 100 lines of code to grab URLs from all current Internet Explorer tabs and drop them in the clipboard. Sometimes .NET programming is very satisfying!

This wasn't a problem with a ClickOnce installer but, for reasons explained elsewhere, I wanted to make a MSI based install package, and MSI technology is bit-width specific. One approach is to create both 32 and 64 bit packages, and have a bootstrapper to choose which to run but I want to avoid that because the content of the two packages would be identical, apart from the flags saying whether they were 64 bit or not. It's also totally the wrong thing for another reason: the MSI bitness declares what flavour of the operating system the package is intended for, and says nothing about the bitness of Office. People run 32 bit Office on 64 bit Windows (I do, for example), so I'd really want a 32 bit installer for this setup, not the 64 bit one.

Let's take a brief step back: what does it mean for the installer to be 64 or 32 bit? Pretty much all that happens is when a 64 bit installer runs on a 64 bit OS, or when a 32 bit one runs on a 32 bit OS, the program files directory maps to (typically) "C:\Program Files" and the registry keys such as HKLM\Software\Microsoft map, not too surprisingly, on to HKLM\Software\Microsoft. However, if you run a 32 bit MSI on a 64 bit OS, program files is mapped to "C:\Program Files (x86)" and that registry key will be sent to HKLM\Software\Wow6432Node\Microsoft - this all happens automatically via "registry reflection." I'm sure there are a few other differences too, but they're not important here. What's more, there's no way (within Windows Installer technology), as far as I'm aware, for a 32 bit MSI package to reach out to the non-redirected parts of the filing system or registry without writing extra code. (For completeness, there's no similar mapping when running a 64 bit installer on a 32 bit OS - primarily because you just can't install 64 bit MSIs on 32 bit Windows!)

Now, the directory in which I place the add-in bits is irrelevant, but the registry is significant... By releasing a 32 bit installer, I was placing the registry stuff under HKLM\Software\Wow6432Node\Microsoft\Office\Outlook on a 64 bit version of Windows - and this so happens to be where 32 bit Outlook looks for its add-ins. People running 64 bit Office would see no add-in because it's looking under HKLM\Software\Microsoft\Office\Outlook. (And the reason that there's no problem with ClickOnce is that it adds the registry settings under HKCU, which doesn't have this redirection and is visible to both 32 and 64 bit Outlook.)

I did consider looking to see what bitness of Office is installed and trying to modify the appropriate part of the registry, but decided against that because I wouldn't want the add-in to "vanish" were someone to uninstall their 32 bit Outlook and then install 64 bit (or vice versa). Instead, I decided that I would always install in the 32 bit friendly location but, on 64 bit Windows, also copy the registry settings "up" as part of the install process. Now, 32 bit applications can't (easily) see the 64 bit parts of the registry because of the automatic redirection, but 64 bit executables get to see everything, so I considered writing a small executable which would run post-install to copy the contents of the appropriate registry key, and also delete it on uninstall. However, then I stumbled across the REG command - which does allow access to the whole registry without me having to write anything more than a command line! In particular, it can copy the contents of one registry key to another, so I can let Windows Installer deal with the 32 bit part of the registry (in a 32 bit installer) as normal, and then use REG to copy what was placed there into the equivalent 64 bit location.

I made the following additions to the WiX Product.wxs file:

    <Property Id="CopyReg64Key" Value='"REG.EXE" COPY "HKLM\Software\WoW6432Node\Microsoft\Office\Outlook\Addins\NoReplyAll" "HKLM\Software\Microsoft\Office\Outlook\Addins\NoReplyAll" /s /f /reg:64' />
    <CustomAction Id="CopyReg64Key" Execute="deferred" Return="ignore" Impersonate="no" BinaryKey="WixCA" DllEntry="CAQuietExec" />

    <Property Id="DeleteReg64Key" Value='"REG.EXE" DELETE "HKLM\Software\Microsoft\Office\Outlook\Addins\NoReplyAll" /f /reg:64' />
    <CustomAction Id="DeleteReg64Key" Execute="deferred" Return="ignore" Impersonate="no" BinaryKey="WixCA" DllEntry="CAQuietExec" />

    <InstallExecuteSequence>
      <Custom Action="CopyReg64Key" Before="InstallFinalize">
        <![CDATA[$CMP_VstoManifest=3]]>
      </Custom>
      <Custom Action="DeleteReg64Key" Before="RemoveFiles">
        <![CDATA[$CMP_VstoManifest=2]]>
      </Custom>
    </InstallExecuteSequence>

The first pair of lines defines a custom action which copies the 32 bit registry entries to the "same place" in the 64 bit part. This will fail silently on a 32 bit operating system, which is fine. Unfortunately it will also fail on Windows XP, since the reg.exe that that comes with doesn't recognise the /reg:64 command line option, but I don't expect that to affect very many people. This is using the WiX quiet execution extension, which lets me invoke a command line without showing a console window - the simpler custom action shown below would cause a brief console flash when it executes:

<CustomAction Id="CopyReg64Key" Execute="deferred" Return="ignore" Impersonate="no" Directory="INSTALLFOLDER"
              ExeCommand='REG COPY "HKLM\Software\WoW6432Node\Microsoft\Office\Outlook\Addins\NoReplyAll" "HKLM\Software\Microsoft\Office\Outlook\Addins\NoReplyAll" /s /f /reg:64' />

The next pair of lines deletes the extra registry setting. On a 32 bit OS, this would delete the same values as the "normal" registry manipulation, so that's OK too. And the final bunch of lines cause the first custom action to be executed near the end of the install sequence and uninstall sequence as appropriate.

With all this in place, the bulk of the installer runs as before, updating the 32 bit parts of the registry. After all that, the custom actions fiddle with the 64 bit part of the registry, and we're done.

Look out for this in the next version of the add-in to be published...