Andrew Whitechapel : Excel UDFs

Excel Services Getting Started – Pt2 UDFs

andreww — Sat, 25 Apr 2009 04:55:00 GMT

This continues my previous checklist on getting started with Excel Services. Here, I’ll append a walkthrough for creating, deploying and updating User-Defined Function assemblies with Excel Services.

4. Create and deploy a UDF assembly

4.1 Create a UDF assembly in Visual Studio (SampleUdf.dll)

a. I’m assuming here that your developer machine is not the same as your Excel Server machine. When you build UDFs, you do need to reference an assembly that is part of Excel Services, but which is unlikely to be available on your dev machine.

b. For simplicity, take a copy of the Microsoft.Office.Excel.Server.Udf.dll from the Excel Server machine, and put it onto your dev machine, so that you can reference it locally. On the Excel Server machine, this DLL is in the GAC, typically here: C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Excel.Server.Udf\12.0.0.0__71e9bce111e9429c\. Copy this to a suitable location on your dev machine.

c. In Visual Studio, create a simple Class Library project. Add a reference to Microsoft.Office.Excel.Server.Udf.dll (and set the Copy Local property to false). You need this for the UdfClass and UdfMethod attributes. Add a suitable using statement for the Microsoft.Office.Excel.Server.Udf namespace.

d. Create a simple class with two methods, using the UdfClass and UdfMethod attributes, eg:

[UdfClass()]

public class MyUdfs

{

[UdfMethod]

public double GetDouble(double d)

{

return d * 2;

}

[UdfMethod(IsVolatile = false)]

public DateTime GetStaticTime()

{

return DateTime.Now;

}

[UdfMethod(IsVolatile = true)]

public DateTime GetVolatileTime()

{

return DateTime.Now;

}

e. In the example above, there are 2 non-volatile methods: GetDouble and GetStaticTime, and one volatile method, GetVolatileTime. GetStaticTime will often return the current time, but Excel Services makes performance optimizations by caching return values of non-volatile methods. So, sometimes Excel Services will return a cached value for GetStaticTime instead of calling the method again. On the other hand, GetVolatileTime will be called every time anything on the sheet is recalculated and re-rendered to the client.

f. Build the DLL.

4.2 Deploy the UDF assembly to Excel Services

a. Copy the UDF DLL from your dev machine to some suitable location on the server machine, eg: “C:\Data\UDFs”. You can deploy UDFs either to an arbitrary file location, or to the GAC. Note that normal probing rules apply, so any dependencies need to be either in the same folder tree as the primary UDF assembly or in the GAC.

b. On the SharePoint Server machine, in Central Administration, select the Application Management tab at the top.

c. Click the SSP link for your Excel Services SSP (by default, “SharedServices1”) to go to the administration page for that SSP.

d. On the Shared Services Administration page, under Excel Services Settings, select the User-defined function assemblies link.

e. Click the Add User Defined Function Assembly option.

f. In the Add User-Defined Function Assembly page, specify the path where you copied the UDF DLL to on the server, eg: “C:\Data\UDFs\SampleUdf.dll”.

g. Specify that this is a File path location, and ensure that the Assembly enabled option is checked. Click OK.

h. The UDF should now be listed on the Excel Services User-Defined Functions page for the SSP.

4.3 Test the UDF assembly (TestSampleUdf.xlsx)

a. Create a new Excel workbook. In Column A, enter labels for the 3 UDFs: Double, StaticTime and VolatileTime. In Column B, enter formulas that call each of these methods:

	A	B	C
1	Double	=GetDouble(C1)	5
2	StaticTime	=GetStaticTime()
3	VolatileTime	=GetVolatileTime()

b. Note that Excel client will return #NAME? for these UDF calls because it cannot find the UDFs on the client. This is expected.

c. Note also that the GetDouble call uses cell C1 as a parameter. Define a name for cell C1, eg: “DoubleParam”.

d. Publish the workbook to Excel Services as normal. Only publish Sheet1, and add a parameter for the DoubleParam cell.

e. When the workbook is published, it is rendered in the browser. You can enter new values for the DoubleParam, and when you click Apply, Excel Services will recalculate the sheet and re-render it.

f. Note that whenever GetDouble is recalculated, so is GetVolatileTime. On the other hand, Excel Services will often return a cached value for GetStaticTime.

4.4 Update the UDF assembly

a. Excel Services loads UDF assemblies when it needs to look for a UDF in a sheet that it is calculating. It only loads each assembly once, and never unloads any assemblies. This makes it difficult to develop iteratively.

b. To force Excel Services to release its lock on a UDF assembly, you can simply recycle the Excel Services application pool.

c. This simple command will recycle the pool:

cd %windir%\system32\inetsrv

appcmd recycle apppool "OfficeServerApplicationPool"

pause

d. You can find the name of the app pool used by Excel Services in IIS Manager, under Application Pools.

e. If necessary, you can also reset IIS altogether, although this is obviously pretty draconian:

net stop iisadmin

rem respond Y

net start w3svc

pause

I hope this continuation checklist is useful – as before, it simply collects together and distils information from a range of documentation on MSDN.

Managed Automation Add-ins

andreww — Thu, 24 Jan 2008 05:11:00 GMT

I've been thinking more about calling unmanaged XLL UDFs from managed code than about managed automation add-ins lately, but an automation add-in issue came up the other day, and I thought I'd throw it out there. If you want to build managed UDFs without going to the extreme of managed XLLs, you have a couple of simple choices:

· You can use a VBA wrapper approach as described in Paul Stubbs' post here:

· Or build an automation add-in instead, as described by Eric Carter here:

… and if you’re going to build a managed automation add-in, you’ll want to shim it, which you can do with the COM Shim Wizard v2.3, described here:

I've blogged about managed UDFs via automation add-ins many times in the past, including the following:

· Implementing IDTExtensibility2 in an Automation Add-in

· Example Shimmed Automation Add-in

· Volatile Managed UDFs

· Optional Volatile UDFs

· Excel Interop Types in Shimmed Automation Add-ins

If you want to build a simple managed automation add-in that does not implement IDTExtensibility2, Eric's excellent post covers the basic procedure. If you do choose this approach, there are a few additional issues you should bear in mind:

· ProgId limitations

· Add-in Manager limitations

· Function Wizard limitations

· Default interface limitations.

Let's take each of these in turn. First, ProgIds. It is common practice in managed code to specify namespaces and typenames that are verbose, but this can easily exceed the maximum allowed length of a ProgId (39 characters). If you do this, there's no indication of the problem until you try to register the add-in with Excel – and even then, Excel simply tells you that the add-in is invalid, without providing any more detail. To avoid this problem, you should always specify a ProgId explicitly, using the ProgId attribute. Also remember that underscores are legal in managed code, but illegal in ProgIds.

Second, Excel's Add-in Manager lists automation add-ins by their registered ProgId, and there is no way to change this behavior. This is an Excel limitation on automation add-ins.

Third, Excel's Function Wizard lists each automation add-in as its own separate function category. The category name is the add-in's ProgId, and you cannot specify a different category name for UDFs in automation add-ins. You also cannot specify function descriptions, argument descriptions, or help for automation add-in UDFs. These are limitations imposed by Excel on automation add-ins, and are described here.

Lastly (as in Eric's post), you can simply attribute the UDF class with ClassInterfaceType.AutoDual. This generates a class interface, which in other contexts is usually frowned upon. A class interface is a generated interface that exposes all public methods, properties, fields and events of the managed type. The basic problem with this is that any changes in a future version to the layout of the type or any base types will break (early-bound) COM clients that bind to the interface. For details see here and here. I discussed the use of class interfaces in automation add-ins in an earlier post. In the specific case of automation add-ins, where the early-bound vtbl interface is not used, the inherent fragility of class interfaces is not in practice a problem. However, there is another problem: display of unwanted methods in the Function Wizard.

Your automation add-in class will implicitly derive from System.Object (all managed classes do). Making the class ComVisible and attributing it with ClassInterfaceType.AutoDual will expose the underlying System.Object methods, Equals, GetHashCode, ToString and GetType. These will be in the typeinfo for the add-in, and will therefore show up in Excel's Insert Function dialog. One approach to prevent these members from showing up is to override them and make them ComVisible(false), as shown below:

[ComVisible(false)]

public override bool Equals(object obj)

{

return base.Equals(obj);

}

[ComVisible(false)]

public override int GetHashCode()

{

return base.GetHashCode();

}

[ComVisible(false)]

public override string ToString()

{

return base.ToString();

}

The problem with this approach is that System.Object.GetType is non-virtual so we cannot override it. So, even if we hide the other 3 methods this way, we'll still be left with GetType.

A second approach is to avoid using a class interface. Instead, specify the UDF interface explicitly, and make it ComVisible(true). Also, attribute your add-in class with ClassInterfaceType.None. A sample class that uses this approach (and suitable explicit ProgId and GUID) is shown below:

[ComVisible(true)]

public interface ISimpleUDFs

{

double MultiplyTwo(double x, double y);

}

[ClassInterface(ClassInterfaceType.None)]

[ComVisible(true)]

[Guid(SimpleUDFs.Guid)]

[ProgId("SimpleAutomationAddIn.SimpleUDFs")]

public class SimpleUDFs : ISimpleUDFs

{

public SimpleUDFs()

{

}

#region Automation Add-in Registration

internal const string Guid = "C426EC79-2F31-44bf-BB0A-BE9A357FA5B3";

const string SubKeyName = @"CLSID\{" + Guid + @"}\Programmable";

[ComRegisterFunction]

public static void RegisterFunction(Type type)

{

Registry.ClassesRoot.CreateSubKey(SimpleUDFs.SubKeyName);

}

[ComUnregisterFunction]

public static void UnRegisterFunction(Type type)

{

Registry.ClassesRoot.DeleteSubKey(SimpleUDFs.SubKeyName);

}

#endregion

public double MultiplyTwo(double x, double y)

{

return x * y;

}

Bear in mind, however, that without a class interface, the default interface on the add-in class will be the first one implemented (that is, ISimpleUDFs in the example above). That means that if your add-in class implements additional interfaces, they will not be visible to automation clients, and any methods defined in such interfaces will not be available as UDFs. That may be a limitation you can live with – after all, you could work around this by simply implementing one interface per class, and exposing multiple classes from your add-in. It may also, of course, be a deliberate part of your design.

If you want to shim your automation add-in (which you should do), you can either write your own shim, or use the COM Shim Wizard. If you want to use the COM Shim Wizard, you need to implement IDTExtensibility2 in your add-in class – this is because the Wizard searches explicitly for this interface when generating a shim for any add-in (both regular COM add-ins and automation add-ins). If you don't need IDTExtensibility2 in your add-in for anything else, then you can simply implement each of its methods in the default manner generated by Visual Studio, for example:

public void OnConnection(

object Application, ext_ConnectMode ConnectMode,

object AddInInst, ref Array custom)

{

throw new Exception("The method or operation is not implemented.");

}

On the other hand, if you do need IDTExtensibility2 (perhaps because you want to get access to Excel's exposed COM OM from your automation add-in), then you're back to generating a class interface for your add-in class (so that you can expose more than one real interface via the combined class interface).

Invoking Native Excel UDFs From Managed Code (Pt2)

andreww — Wed, 02 Jan 2008 01:48:00 GMT

In my previous post, I looked at how to build a VSTO add-in that invokes native XLL UDFs via the Excel COM OM (specifically, Application.Run). In this second part, I'll look at the same managed client calling the same XLL UDFs via the Windows API instead of Excel's COM OM, specifically using LoadLibrary and GetProcAddress.

Continuing with the same VSTO add-in project I used last time, I added a class for the native imports (I looked up pinvoke.net for the signatures). I also declared a delegate which I can use in my managed code to represent the XLL function pointer:

internal static class NativeTypes

{

[DllImport("kernel32.dll")]

internal static extern IntPtr LoadLibrary(string lpFileName);

[DllImport("kernel32.dll", CharSet=CharSet.Ansi,

ExactSpelling=true, SetLastError=true)]

internal static extern IntPtr GetProcAddress(

IntPtr hModule, string procName);

internal delegate IntPtr UdfDelegate();

}

Back in my Ribbon class, I added a couple of fields for the XLL filename and the XLL module handle. The idea is that I only need to get the XLL module handle once, and this is not really part of the perf timing I need to include. That is, although there will be some perf cost to calling LoadLibrary, it is pretty minimal and a realistic solution would only call this once so it should not be included on the per-call timings. Note that LoadLibrary will not load the XLL again if it is already mapped into the process (which it should be by the time I call it, because XLLs are loaded before COM add-ins). So, in the onLoad callback for the Ribbon customization, I first make sure that the XLL is actually loaded, by walking the collection of Excel.AddIns, and then I use LoadLibrary to get its module handle:

private const string xllName = "SimpleXll2007.xll";

private IntPtr xllHandle;

public void Ribbon_Load(Office.IRibbonUI ribbonUI)

{

this.ribbon = ribbonUI;

foreach (

Excel.AddIn addIn in Globals.ThisAddIn.Application.AddIns)

{

if (addIn.Name == xllName)

{

// Cache the module handle for the XLL to target.

xllHandle = NativeTypes.LoadLibrary(xllName);

}

The next task is to call one of the UDFs. I get the address of the UDF using GetProcAddress. Then, I can use the System.Runtime.InteropServices.Marshal.GetDelegateForFunctionPointer to get a managed delegate mapping to the raw function pointer – using my custom delegate type to store the result. From there, I can invoke the UDF by invoking the delegate. Finally, I can use Marshal.PtrToStringAnsi to convert the returned char* to a managed string:

IntPtr fptr = NativeTypes.GetProcAddress(xllHandle, "GetChars");

NativeTypes.UdfDelegate invoker = (NativeTypes.UdfDelegate)

Marshal.GetDelegateForFunctionPointer(

fptr, typeof(NativeTypes.UdfDelegate));

IntPtr ip = invoker();

string s1 = Marshal.PtrToStringAnsi(ip);

For the GetString UDF, life is a little more interesting. This UDF returns an XLOPER. I can get the address of the UDF and invoke it via a delegate in the same way as for the simpler GetChars UDF:

fptr = NativeTypes.GetProcAddress(xllHandle, "GetString");

invoker = (NativeTypes.UdfDelegate)

Marshal.GetDelegateForFunctionPointer(

fptr, typeof(NativeTypes.UdfDelegate));

ip = invoker();

…but to convert the returned IntPtr, which represents a pointer to an XLOPER, to a managed type requires a bit more work. Essentially, I need to define a managed equivalent of the XLOPER struct. I've put these in my NativeTypes class. The XLOPER type is a struct which contains a flag to indicate the type of the data, and a set of nested unions to represent the data, defined in xlcall.h in the Excel XLL SDK. Conceptually, this is very similar to the VARIANT type in COM automation. Note: the managed equivalent listed below is not complete, because it does not include the more complex XLOPER union members such as arrays and cell references. The XlVal and XlOper structs together represent a much simplified XLOPER. Also note that to represent a native union, I'm using the FieldOffset attribute with a zero value. In order to use FieldOffset, the struct has to be declared unsafe. This means that the project has to be built to allow unsafe code (Project Properties | Build | Allow unsafe code).

[StructLayout(LayoutKind.Explicit)]

internal unsafe struct XlVal

{

[FieldOffset(0)]

public double num;

[FieldOffset(0)]

public XlString* str;

[FieldOffset(0)]

public ushort xbool;

[FieldOffset(0)]

public short w;

[FieldOffset(0)]

public XlError err;

}

public struct XlOper

{

public XlVal val;

public XlType xlType;

}

To complete the definition, I also defined an enum for the XLOPER type, an enum for the XLOPER error values, and a simple struct to represent the XLOPER string type (which is octal-length-prefixed). All of these are designed to map to their native equivalents defined in xlcall.h:

// XLOPER data types, used for the xlType field of the XlOper struct.

[Flags]

internal enum XlType : ushort

{

xlTypeNum = 0x0001,

xlTypeStr = 0x0002,

xlTypeBool = 0x0004,

xlTypeRef = 0x0008,

xlTypeErr = 0x0010,

xlTypeFlow = 0x0020,

xlTypeMulti = 0x0040,

xlTypeMissing = 0x0080,

xlTypeNil = 0x0100,

xlTypeSRef = 0x0400,

xlTypeInt = 0x0800,

xlBitxLFree = 0x1000,

xlBitDLLFree = 0x4000,

xlTypeBigData = xlTypeStr | xlTypeInt

}

// Error codes, used for the val.err field of the XlOper struct.

public enum XlError : ushort

{

xlErrorNull = 0,

xlErrorDiv0 = 7,

xlErrorValue = 15,

xlErrorRef = 23,

xlErrorName = 29,

xlErrorNum = 36,

xlErrorNA = 42

}

// XLOPER strings are octal-length-prefixed.

internal unsafe struct XlString

{

public short length;

public fixed byte data[255];

}

Armed with this managed XlOper type, I can use Marshal.PtrToStructure to convert the IntPtr returned by the UDF delgate to an instance of the managed XlOper type, extract the data member, and then extract the unicode string from that.

NativeTypes.XlOper xlOper = (NativeTypes.XlOper)

Marshal.PtrToStructure(ip, typeof(NativeTypes.XlOper));

string s2 = String.Empty;

unsafe

{

s2 = Marshal.PtrToStringUni(

new IntPtr(xlOper.val.str->data));

}

The complete event handler for the Win API Ribbon button is listed below, including both UDF calls and the perf timing code.

public void OnButtonWinApi(Office.IRibbonControl control)

{

if (xllHandle == null || xllHandle.ToInt32() == 0)

{

return;

}

long ticksAccumulated = 0;

Stopwatch watch;

for (int i = 0; i < repeatCount; i++)

{

// Perf-count this method call.

watch = Stopwatch.StartNew();

try

{

// Call the GetChars UDF, which returns a char*.

IntPtr fptr =

NativeTypes.GetProcAddress(

xllHandle, "GetChars");

NativeTypes.UdfDelegate invoker =

(NativeTypes.UdfDelegate)

Marshal.GetDelegateForFunctionPointer(

fptr, typeof(NativeTypes.UdfDelegate));

IntPtr ip = invoker();

string s1 = Marshal.PtrToStringAnsi(ip);

// Call GetString (which returns an XLOPER*).

fptr = NativeTypes.GetProcAddress(

xllHandle, "GetString");

invoker = (NativeTypes.UdfDelegate)

Marshal.GetDelegateForFunctionPointer(

fptr, typeof(NativeTypes.UdfDelegate));

ip = invoker();

NativeTypes.XlOper xlOper = (NativeTypes.XlOper)

Marshal.PtrToStructure(

ip, typeof(NativeTypes.XlOper));

string s2 = String.Empty;

unsafe

{

s2 = Marshal.PtrToStringUni(

new IntPtr(xlOper.val.str->data));

}

Globals.ThisAddIn.Application.ActiveCell.Value2 =

String.Format("{0}, {1}", s1, s2);

}

catch (Exception ex)

{

Debug.WriteLine(ex.ToString());

}

// Keep a running total of the elapsed call time.

ticksAccumulated += watch.ElapsedTicks;

}

// Calculate and report the average elapsed time.

Debug.WriteLine(String.Format(

"LoadLibrary/GetProcAddress: average = {0} msec",

(ticksAccumulated * msecPerTick) / repeatCount));

}

Over a large number of invocations (10,000), repeated over 100 runs, calling UDFs via the Windows API averaged out at 0.9851 msec. Recall that the same set of tests using the COM OM averaged out at 1.9625 msec. So, it seems that – in the simple case at least – using the Windows API and avoiding COM interop is almost exactly twice as fast. Of course, these results are skewed slightly because my managed XlOper type is so simplified, and I haven't tested the performance when a UDF takes and/or returns complex XLOPERs made up of cell references or arrays.

Invoking Native Excel UDFs From Managed Code (Pt1)

andreww — Fri, 14 Dec 2007 06:54:00 GMT

As part of a little ongoing investigation, I wanted to communicate between a managed add-in and a native XLL UDF. As I was writing this up, it turned out to be a much longer post that I planned, so I've split it into two parts (I'll post the second part in the next week or so, mince pies permitting).

Obviously, you can build managed code to invoke methods exposed by the Excel COM object model. The question is, can you build managed code – in an add-in, say – to invoke unmanaged UDFs (which are not part of the COM OM). More specifically, can your managed code invoke unmanaged UDFs exposed not by a COM-based automation add-in but by a regular XLL (which is really little more than a regular native Windows DLL)?

Well, obviously, since I'm blogging it, the answer is "Yes". There are several techniques you could use, and of these, one or two that are actually practical:

· If the XLL additionally implements some COM interface, we could then use COM interop from the managed client to invoke UDFs either using a static typelib/interop assembly or using runtime reflection. We could get the XLL COM object from the Excel.AddIns collection. However, requiring an XLL to implement a COM interface is a pretty unnatural act, so we won't consider that further.

· The Excel C API includes the xlUDF identifer for the Excel4/Excel12 function: this is designed specifically to invoke UDFs. However, to use this in a managed client would require p/invoke to the Excel4/Excel12 function in xlcall32.lib. We could do this using DllImport, but this requires a DLL as its parameter, which would therefore require you to build xlcall32.lib into a DLL, so this is pretty unnatural also – and we won't consider this further either.

· The managed client could use the Excel COM OM, specifically Application.Run – which can be used to invoke any VBA macro or UDF. The benefits of this approach include that it is documented and supported, and that because it uses COM interop to talk to Excel, parameter and return type marshaling is done for you. The disadvantage is that because it uses COM interop, there is a perf overhead.

· Another option is to p/invoke to the Windows API functions LoadLibrary and GetProcAddress to get a direct pointer to the UDF. LoadLibrary will use the already-loaded XLL if it is already mapped into the process. We can then use Marshal.GetDelegateForFunctionPointer to map the UDF pointer returned by GetProcAddress to a managed delegate. The disadvantage of this is that we have to do all the marshaling manually. The advantage is that avoiding the COM interop layer may give us a perf boost.

Really, it was the last question that interested me: is it worth doing all the manual marshaling in order to avoid the COM interop layer? (Of course, this is actually a general question that also applies outside the context of Office programmability.) Also, how interesting is that marshaling, given that the Excel C API likes to use XLOPERs for parameter and return types?

To continue this investigation, I first created a simple native XLL, following the guidelines in the updated Excel 2007 XLL SDK. See my previous post for details of how to create a native XLL with VS 2008.

Next, I created a VSTO Excel 2007 add-in. I added a Ribbon (XML) item. I used a Ribbon (XML) item as opposed to a Ribbon (Visual Designer) item, because while the VSTO Ribbon visual designer is a wonderful RAD tool, I sometimes prefer to work with the XML directly and avoid the overhead of the VSTO Ribbon OM. In particular, it's easier to show the complete code in a blog post for an XML-based Ribbon than it is for a VSTO OM-based Ribbon. Here's my Ribbon XML:

<?xml version="1.0" encoding="UTF-8"?>

<tabs>

<group id="groupVstoInvoker"

label="VstoInvoker">

<button id="buttonComOm"

label="COM OM"

imageMso="AdpStoredProcedureQueryMakeTable"

size="large"

onAction="OnButtonComOm"/>

<button id="buttonWinApi"

label="Win API"

imageMso="AdpStoredProcedureQueryUpdate"

size="large"

onAction="OnButtonWinApi"/>

<editBox id="editBoxRepeat"

label="Repeat"

sizeString="wwwww"

onChange="OnEditBoxRepeat"/>

</group>

</tab>

</tabs>

</ribbon>

</customUI>

The screenshot below shows how it's rendered at runtime. There are 2 buttons, one for invoking a UDF via the Excel COM OM and a second button for invoking a UDF via the Windows API. The "Repeat" editbox allows the user to specify the number of times to invoke the UDF repeatedly (defaults to 1).

The various Ribbon event handlers are listed below. The onAction handler for the Win API button is currently just stubbed out (I'll implement this in Pt.2). The editbox onChange handler converts the editbox text to an integer and caches it as the UDF invocation repeat count. The onAction handler for the COM OM button does the work to invoke the target UDF via Excel's exposed COM OM. The UDF invocation deliberately includes a call to a UDF that takes and returns a simple type (char*) as well as one that uses an XLOPER.

private int repeatCount = 1;

public void OnEditBoxRepeat(Office.IRibbonControl control, string text)

{

try

{

repeatCount = Convert.ToInt32(text);

}

catch (Exception ex)

{

Debug.WriteLine(ex.ToString());

}

if (repeatCount == 0)

{

repeatCount = 1;

}

public void OnButtonComOm(Office.IRibbonControl control)

{

for (int i = 0; i < repeatCount; i++)

{

try

{

// Call the GetChars UDF, which returns a simple char*.

object m = Type.Missing;

object o1 = Globals.ThisAddIn.Application.Run(

"GetChars",

m, m, m, m, m, m, m, m, m, m, m, m, m, m, m,

m, m, m, m, m, m, m, m, m, m, m, m, m, m, m);

// Call GetString (which returns an XLOPER).

object o2 = Globals.ThisAddIn.Application.Run(

"GetString",

m, m, m, m, m, m, m, m, m, m, m, m, m, m, m,

m, m, m, m, m, m, m, m, m, m, m, m, m, m, m);

Globals.ThisAddIn.Application.ActiveCell.Value2 =

String.Format("{0}, {1}", o1, o2);

}

catch (Exception ex)

{

Debug.WriteLine(ex.ToString());

}

As you can see, I can call both GetChars and GetString UDFs in the same way, even though one returns a double and the other an XLOPER – I don't have to worry about converting between XLOPERs and managed types, because this is all done for me by the COM interop layer. When I get the return value from the UDF, I'm simply setting it into the current active cell. So, this approach is pretty simple from the developer's perspective. That's one advantage. The other aspect I wanted to check was performance, so I layered on some simple timing code using the System.Diagnostics.Stopwatch class, as shown below.

private double msecPerTick = 1000.0 / Stopwatch.Frequency;

public void OnButtonComOm(Office.IRibbonControl control)

{

long ticksAccumulated = 0;

Stopwatch watch;

for (int i = 0; i < repeatCount; i++)

{

// Perf-count this method call.

watch = Stopwatch.StartNew();

try

{

// Call the UDFs.

}

catch (Exception ex)

{

Debug.WriteLine(ex.ToString());

}

// Keep a running total of the elapsed call time.

ticksAccumulated += watch.ElapsedTicks;

}

// Calculate and report the average elapsed time.

Debug.WriteLine(String.Format(

"Application.Run: average = {0} msec",

(ticksAccumulated * msecPerTick) / repeatCount));

}

Note that I'm including the cell access operation as part of the timing instead of restricting the timing to the raw UDF call alone, because this is a fairly likely scenario, and I wanted to make sure that I included it so as not to miss any potential context switch that might take place between calling the UDF and accessing the Excel UI through the OM. To view the perf timing output, I used DebugView, downloadable here. Over a large number of invocations (10,000), repeated over 100 runs, calling my UDFs via Excel's COM OM averaged out at 1.9625 msec (on my HP Compaq NC8430 notebook, Centrino duo T7400 2.16 GHz, 3.37 Gb RAM, running Vista Ultimate 64bit). Next, I'll look at how to do the job using the Windows API.

Building an Excel XLL in C/C++ with VS 2008

andreww — Mon, 10 Dec 2007 04:24:00 GMT

As part of a little investigation I'm doing at present, I needed to build some simple native XLLs for testing purposes. This was the first time I had a need to build XLLs since the Excel XLL SDK was updated back in September. The updated Excel 2007 XLL SDK is available for free download here. The online documentation is here. There's also an old support article on how to build an XLL with C++ here – this refers to the Excel 97 SDK, but the information is still valid (although it doesn't use any of the new types such as XLOPER12). The significant changes between the Excel 97 SDK and the Excel 2007 SDK are described here. In building my simple test XLLs, I based my code on the sample code in the SDK. I didn't find any startling new information beyond the documentation, but I did encounter a few interesting issues which I thought I'd share here.

For my purposes, I wanted the simplest possible project. To start off, I created a new Visual C++ | Win32 Application project (called SimpleXll2007), and in the Win32 Application project wizard I changed the Application Type to DLL. When the wizard had generated the starter project, I deleted all the .H and .CPP source files from the project. Then I set the following project settings:

· C++ | Additional include directories: "C:\Program Files (x86)\Excel2007XllSdk\include"

· C++ | Precompiled Headers: Not Using Precompiled Headers

· Linker | General | Output file: $(OutDir)\$(ProjectName).xll

· Linker | General | Additional library directories: "C:\Program Files (x86)\Excel2007XllSdk\lib"

· Linker | Input | Additional dependencies: xlcall32.lib frmwrk32.lib

· Linker | Input | Module definition file: $(ProjectDir)$(ProjectName).def

· Debugging | Command: C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE

To explain these: I needed to specify additional search paths for #includes and static linked libs because an XLL project will want to use the Excel XLL SDK headers and libraries (primarily, xlcall.h/xlcall32.lib which essentially constitute the Excel C API, and framewrk.h/frmwrk32.lib which provide additional helper functions). On my Vista machine, I had installed the SDK to C:\Program Files(x86)\Excel2007XllSdk. I had to specify that the target output should have an XLL extension not the default DLL. As one of the standard options for exporting functions, I chose to implement a DEF file. For debugging, I wanted to be able to just press F5 on the project and have VS launch Excel for me.

Next, I added the following new (empty) files to the project:

· SimpleXll2007.def – lists the exported functions.

· UDFs.h – defines the metadata for my UDFs (function type, signature, helpstrings, etc).

· UDFs.c – implementation of my UDFs.

· xlFunctions.c – implementation of the standard XLL exports that Excel will call back on.

The DEF file is pretty simple. It lists the standard XLL exports (xlAutoOpen, etc) and the custom UDF exports (SumTwo, etc):

LIBRARY SimpleXll2007.xll

EXPORTS

; Standard XLL functions

xlAutoOpen

xlAutoClose

xlAutoRegister12

xlAutoAdd

xlAutoRemove

xlAddInManagerInfo12

; UDFs

SumTwo

GetString

GetChars

The header file (UDFs.h) defines the UDF metadata. As this defines values, not just types, this should probably be in a .C file, but the data is used when registering the UDFs, and the UDF-registering functions are part of the standard XLL exports (xlAutoOpen, etc) – and I wanted to separate out these generic functions from the metadata for my specific UDFs. For each function, I set up an array of strings for the metadata, and put all these arrays into an outer array – this enables me to register the UDF metadata in a simple loop later on. The only downside is that I need the arrays to be regular – that is, each sub-array must have the same number of elements. As some of the elements are for helpstrings for the UDF arguments, and as the number of UDF arguments varies, this forces me to define empty strings for some of my UDF argument help metadata values. The metadata values will eventually be passed to the Excel4/Excel12 function and its variants when the UDFs are registered in my implementation of xlAutoOpen and xlAutoRegister12.

// UDFs.h

#define g_rgNumUDFs 5

#define g_rgUDFdata 11

static LPWSTR g_rgUDFs

[g_rgNumUDFs][g_rgUDFdata] =

{

L"SumTwo", // Function name/ordinal

L"JJJ", // Func signature type

L"SumTwo", // Func name in Func wizard

L"Arg1, Arg2", // Arg name in Func wizard

L"1", // Function type

L"SimpleXll2007", // Category in Func wizard

L"", // Shortcut (commands only)

L"", // Help topic

L"SumTwo function help", // Func help in Func wizard

L"Help for Arg1", // Arg help in Func wizard

L"Help for Arg2" // Arg help in Func wizard

{

L"GetString",

L"U",

L"GetString",

L"",

L"1",

L"SimpleXll2007",

L"",

L"GetString function help",

L"",

L""

{

L"GetChars",

L"C",

L"GetChars",

L"",

L"1",

L"SimpleXll2007",

L"",

L"GetChars function help",

L"",

L""

};

As you can see, the UDFs are pretty simple. The GetString and GetChars function signatures are almost identical – but I specifically wanted to test a UDF that returns a string as simple type such as a char* (specified as "C" when registering with Excel) as well as one that returns a string as an XLOPER/XLOPER12 ("U"). The SumTwo function returns a long ("J") and takes 2 long args ("JJ"). Descriptions of the function signature identifiers are here.

These functions are implemented in the file UDFs.c (see comments inline below):

// UDFs.c

#include <windows.h>

#include <xlcall.h>

#include <framewrk.h>

#include <stdio.h>

// Example UDF that adds two numbers passed as longs, and

// returns a long.

__declspec(dllexport) long SumTwo(long arg1, long arg2)

{

return arg1 + arg2;

}

// Example UDF that simply returns a string as an XLOPER12.

// Note that the string is length-prefixed in octal.

__declspec(dllexport) LPXLOPER12 WINAPI GetString (void)

{

static XLOPER12 xResult;

xResult.xltype = xltypeStr;

xResult.val.str = L"\024Hello from GetString";

return(LPXLOPER12) &xResult;

}

// Example UDF that returns a null terminated string in a char*.

__declspec(dllexport) char* WINAPI GetChars(void)

{

char* pszNewString = NULL;

size_t cBytes;

cBytes = strlen("Hello from GetChars") + 1;

pszNewString = (char*)malloc(cBytes);

sprintf_s(pszNewString, cBytes, "Hello from GetChars");

return pszNewString;

}

Finally, my xlFunctions.c file contains the standard XLL exports (xlAutoOpen, etc). This is very generic, and I pretty much just cut+pasted from the SDK sample code for these, with a few minor tweaks. I did remove the sample code for command and menu functions, because I only needed to test worksheet functions. I also sprinkled a few debugPrintfs around for good measure.

// xlFunctions.c

#include <windows.h>

#include <xlcall.h>

#include <framewrk.h>

#include "UDFs.h"

// Compares two strings for equality (case-insensitive).

int lpwstricmp(LPWSTR s, LPWSTR t)

{

int i;

if (wcslen(s) != *t)

{

return 1;

}

for (i = 1; i <= s[0]; i++)

{

if (towlower(s[i-1]) != towlower(t[i]))

{

return 1;

}

return 0;

}

BOOL APIENTRY DllMain( HANDLE hDLL, DWORD dwReason, LPVOID lpReserved )

{

switch (dwReason)

{

case DLL_PROCESS_ATTACH:

case DLL_PROCESS_DETACH:

case DLL_THREAD_ATTACH:

case DLL_THREAD_DETACH:

default:

break;

}

return TRUE;

}

// Excel calls xlAutoOpen when it loads the XLL.

__declspec(dllexport) int WINAPI xlAutoOpen(void)

{

static XLOPER12 xDLL; // The filename of this XLL.

int i;

debugPrintf("xlAutoOpen\n");

// Fetch the name of this XLL. This is used as the first arg

// to the REGISTER function to specify the name of the XLL.

Excel12f(xlGetName, &xDLL, 0);

debugPrintf("XLL Name: %S\n", xDLL.val.str);

// Loop through the g_rgUDFs[] table, registering each

// function in the table using xlfRegister.

for (i = 0; i < g_rgNumUDFs; i++)

{

Excel12f(xlfRegister, 0, 1 + g_rgUDFdata,

(LPXLOPER12) &xDLL,

(LPXLOPER12) TempStr12(g_rgUDFs[i][0]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][1]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][2]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][3]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][4]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][5]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][6]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][7]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][8]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][9]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][10])

);

}

// Free the XLL filename.

Excel12f(xlFree, 0, 1, (LPXLOPER12) &xDLL);

return 1;

}

// Excel calls xlAutoClose when it unloads the XLL.

__declspec(dllexport) int WINAPI xlAutoClose(void)

{

int i;

debugPrintf("xlAutoClose\n");

// Delete all names added by xlAutoOpen or xlAutoRegister.

for (i = 0; i < g_rgNumUDFs; i++)

{

Excel12f(xlfSetName, 0, 1, TempStr12(g_rgUDFs[i][2]));

}

return 1;

}

// Excel calls xlAutoRegister12 if a macro sheet tries to register

// a function without specifying the type_text argument.

__declspec(dllexport) LPXLOPER12 WINAPI xlAutoRegister12(LPXLOPER12 pxName)

{

static XLOPER12 xDLL, xRegId;

int i;

debugPrintf("xlAutoRegister12\n");

xRegId.xltype = xltypeErr;

xRegId.val.err = xlerrValue;

for (i = 0; i < g_rgNumUDFs; i++)

{

if (!lpwstricmp(g_rgUDFs[i][0], pxName->val.str))

{

Excel12f(xlfRegister, 0, 1 + g_rgUDFdata,

(LPXLOPER12) &xDLL,

(LPXLOPER12) TempStr12(g_rgUDFs[i][0]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][1]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][2]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][3]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][4]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][5]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][6]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][7]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][8]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][9]),

(LPXLOPER12) TempStr12(g_rgUDFs[i][10])

);

// Free the oper returned by Excel.

Excel12f(xlFree, 0, 1, (LPXLOPER12) &xDLL);

return(LPXLOPER12) &xRegId;

}

return(LPXLOPER12) &xRegId;

}

// When you add an XLL to the list of active add-ins, the Add-in

// Manager calls xlAutoAdd() and then opens the XLL, which in turn

// calls xlAutoOpen.

__declspec(dllexport) int WINAPI xlAutoAdd(void)

{

debugPrintf("xlAutoAdd\n");

return 1;

}

// When you remove an XLL from the list of active add-ins, the

// Add-in Manager calls xlAutoRemove() and then

// UNREGISTER("SimpleXll2007.XLL").

__declspec(dllexport) int WINAPI xlAutoRemove(void)

{

debugPrintf("xlAutoRemove\n");

return 1;

}

// The Excel Add-in Manager calls xlAddInManagerInfo12 function

// to find the long name of the add-in.

__declspec(dllexport) LPXLOPER12 WINAPI xlAddInManagerInfo12(LPXLOPER12 xAction)

{

static XLOPER12 xInfo, xIntAction;

debugPrintf("xlAutoAddInManagerInfo12\n");

// This code coerces the passed-in value to an integer.

Excel12f(xlCoerce, &xIntAction, 2, xAction,

TempInt12(xltypeInt));

if (xIntAction.val.w == 1)

{

// Note that the string is length-prefixed in octal.

xInfo.xltype = xltypeStr;

xInfo.val.str = L"\016SimpleXll2007";

}

else

{

xInfo.xltype = xltypeErr;

xInfo.val.err = xlerrValue;

}

// Word of caution: returning static XLOPERs/XLOPER12s is

// not thread-safe. For UDFs declared as thread-safe, use

// alternate memory allocation mechanisms.

return(LPXLOPER12) &xInfo;

}

After building the project, F5 runs Excel. You still need to register the XLL with Excel, and you can do this in the UI by going to File | Excel Options | Add-ins. Drop down the Manage listbox, and select Excel Add-ins to display the Excel Add-ins dialog (not the COM Add-ins dialog). Click the Browse button and navigate to the SimpleXll2007.xll to register this XLL with Excel:

After this, you can go to the Formulas tab and click Insert Function – you can see some of the UDF metadata surfaced in the Insert Function wizard dialog:

Excel Interop Types in Shimmed Automation Add-ins

andreww — Sun, 23 Jul 2006 22:00:00 GMT

In my previous posts on shimming Excel automation add-in UDFs, I've used simple examples where the methods tended to take and return standard types such as doubles and ints. Someone asked a question recently - what about Excel types as parameters? In other words, how do you write the shim for a method that takes say an Excel Range object as a parameter?

So, here's an example.

The simplest process to adopt is to build a regular COM add-in (that implements IDTExtensibility2), and then shim it. This way, you can use the COM Shim Wizards to generate the shim code. You can always remove the IDTExtensibility2 implementation from the add-in and shim later, if you don’t want them. That said, it is generally useful to implement IDTExtensibility2 in your automation add-in, if only because Excel then gives you an Excel.Application object up front – which is otherwise somewhat difficult to get.

In my managed automation add-in assembly, I declare my UDF in a custom interface. Note that I’m using standard Excel interop types, such as Excel.Range:

namespace RangeUDF

{

[GuidAttribute("73570AB7-89E3-45e4-B605-B6DDFFE7C437")]

public interface IRangeCalc

{

double SumValues(Excel.Range r);

}

…and implement it in a class like this:

[GuidAttribute("3C8ED961-B58B-4580-AB67-A45648E2A7B7"),

ProgId("RangeUDF.Connect"),

ClassInterface(ClassInterfaceType.AutoDual)]

public class Connect :

Object, Extensibility.IDTExtensibility2, IRangeCalc

{

#region Standard IDTExtensibility2 stuff

public Connect(){}

public void OnConnection(object application,

Extensibility.ext_ConnectMode connectMode,

object addInInst, ref System.Array custom)

{

xl = (Excel.Application)application;

addInInstance = addInInst;

}

public void OnDisconnection(

Extensibility.ext_DisconnectMode disconnectMode,

ref System.Array custom) { }

public void OnAddInsUpdate(ref System.Array custom){}

public void OnStartupComplete(ref System.Array custom){}

public void OnBeginShutdown(ref System.Array custom){}

private Excel.Application xl;

private object addInInstance;

#endregion

#region IRangeCalc Members

public double SumValues(Excel.Range r)

{

double sum = 0;

for (int row = 1; row <= r.Rows.Count; row++)

{

for (int col = 1; col <= r.Columns.Count; col++)

{

sum += Convert.ToDouble(

((Excel.Range)r.Cells[row, col]).Value2);

}

return sum;

}

#endregion

}

Note: make sure you know what the GUID is for your assembly. The simplest way to do this is to go to the properties for the project, then the Application tab, and click on Assembly Information. Specify a new GUID in the GUID field. This ends up in the assemblyinfo.cs. At the same time, check the box to make the assembly COM-visible, and on the build tab, check the box to register it for COM interop. For example, in my assemblyinfo.cs, I end up with this declaration:

[assembly: GuidAttribute("917E2CFA-D16C-41b4-BD33-6EE0254C98FD")]

...this is the GUID for the assembly (and therefore, eventually, the COM typelib).

So far, nothing unusual.

Now for the shim. You can use the COM Shim Wizards to generate the basic COM add-in shim code as usual. Then, you need to modify the code to turn it into an automation add-in shim.

The first critical change is to import the typelib for the managed assembly into the shim project. If you look at the stdafx.h, you’ll see #imports for the mscorlib an msaddndr typelibs, which give you the declarations of _AppDomain and IDTExtensibility2, respectively. For your shim, add another #import for the typelib of your managed assembly, eg:

// Imports the typelib for the RangeUDF add-in assembly.

#import "libid:917E2CFA-D16C-41b4-BD33-6EE0254C98FD" raw_interfaces_only named_guids

Recall that the stdafx.h is used for the precompiled headers. This #import will import the typelib and therefore generate a .TLH. You should get intellisense for this typelib in your project straight away. If you want to see a persisted copy of the .TLH, you can build your project at this point.

In the ConnectProxy.h, update the proxy class so that it implements your custom interface in addition to (or instead of) IDTExtensibility2. As soon as you type the namespace for the custom interface (and the double colon), intellisense/autocomplete should give you a dropdown list of members from the typelib:

class ATL_NO_VTABLE CConnectProxy :

public CComObjectRootEx<CComSingleThreadModel>,

public CComCoClass<CConnectProxy, &CLSID_ConnectProxy>,

public IDispatchImpl<AddInDesignerObjects::_IDTExtensibility2,

&AddInDesignerObjects::IID__IDTExtensibility2,

&AddInDesignerObjects::LIBID_AddInDesignerObjects, 1, 0>,

public IDispatchImpl<RangeUDF::IRangeCalc,

&RangeUDF::IID_IRangeCalc,

&RangeUDF::LIBID_RangeUDF, 1, 0>

{

As well as (or instead of) the IDTExtensibility2 pointer that the wizard gives you, add a declaration for your custom interface pointer:

protected:

RangeUDF::IRangeCalc *m_pRangeCalc;

Initialize your custom interface pointer in the constructor:

CConnectProxy() : m_pConnect(NULL), m_pCLRLoader(NULL), isShutdownInProgress(false), m_pRangeCalc(NULL)

{

}

Note that the isShutdownInProgress field is specific to the VS 2005 version of the COM Shim Wizards.

Update the COM map to (a) include your custom interface, and (b) route queries for IDispatch through your custom interface:

BEGIN_COM_MAP(CConnectProxy)

//COM_INTERFACE_ENTRY2(IDispatch, AddInDesignerObjects::IDTExtensibility2)

COM_INTERFACE_ENTRY(RangeUDF::IRangeCalc)

COM_INTERFACE_ENTRY2(IDispatch, RangeUDF::IRangeCalc)

COM_INTERFACE_ENTRY(AddInDesignerObjects::IDTExtensibility2)

END_COM_MAP()

If you’re using the VS 2005 version of the COM Shim Wizards, update the OnDisconnection proxy to clean up your custom interface pointer:

STDMETHOD(OnDisconnection)(

AddInDesignerObjects::ext_DisconnectMode RemoveMode, SAFEARRAY **custom )

{

HRESULT hr = S_OK;

if (m_pConnect)

{

hr = m_pConnect->OnDisconnection(RemoveMode, custom);

if (SUCCEEDED(hr))

{

m_pConnect->Release();

m_pConnect = NULL;

m_pRangeCalc->Release();

m_pRangeCalc = NULL;

// Only try to unload the AppDomain if the host application

// has not started a shutdown.

if (!isShutdownInProgress)

{

if (m_pCLRLoader)

{

// Unload the AppDomain, and null the pointer to make

// sure we only do this once.

hr = m_pCLRLoader->Unload();

m_pCLRLoader = NULL;

}

return hr;

}

If you’re implementing IDTExtensibility2 in your shim, you can leave the rest of the IDTExtensibility2 methods just as the wizard generated them.

Next, implement your custom interface method(s), as illustrated below. Once you have the .TLH for your custom typelib, all the types declared in it become available to intellisense. So, for example, declaring an Excel Range parameter turns out to be pretty simple:

//IRangeCalc implementation:

STDMETHOD(SumValues)(RangeUDF::Range *r, double *pRetVal)

{

return m_pRangeCalc->SumValues(r, pRetVal);

}

Finally, in the ConnectProxy.cpp, find the implementation of FinalConstruct. The wizard-generated code will give you everything you need to set up the shim and connect it to the managed assembly. You need to add a line to get from the IDTExtensibility2 pointer to the custom UDF interface, via QueryInterface, eg:

HRESULT CConnectProxy::FinalConstruct()

{

HRESULT hr = S_OK;

// Create an instance of a managed addin

// and fetch the interface pointer

m_pCLRLoader = CCLRLoader::TheInstance();

IfNullGo(m_pCLRLoader);

IfFailGo(m_pCLRLoader->CreateInstance(AssemblyName(), ConnectClassName(),

__uuidof(IDTExtensibility2), (void **)&m_pConnect));

// Initialize the RangeCalc pointer.

IfFailGo(m_pConnect->QueryInterface(

__uuidof(RangeUDF::IRangeCalc), (void **)&m_pRangeCalc));

Error:

return hr;

}

The last step is to build everything, make sure the managed assembly lives in the same folder as the shim DLL, make sure the shim is registered, and make sure the add-in typelib is registered. You should configure your setup project to do all these things, and/or custom build steps for your shim project. Alternatively, for the registration pieces, you can write a simple .REG file and merge it into the registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\RangeUDF.Connect]

@="RangeUDF.Connect"

[HKEY_CLASSES_ROOT\RangeUDF.Connect\CLSID]

@="{3c8ed961-b58b-4580-ab67-a45648e2a7b7}"

[HKEY_CLASSES_ROOT\CLSID\{3c8ed961-b58b-4580-ab67-a45648e2a7b7}]

@="RangeUDF.Connect"

[HKEY_CLASSES_ROOT\CLSID\{3c8ed961-b58b-4580-ab67-a45648e2a7b7}\InprocServer32]

@="C:\\Temp\\RangeUDF_shimmed\\RangeUDFShim\\Debug\\RangeUDFShim.dll"

"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\CLSID\{3c8ed961-b58b-4580-ab67-a45648e2a7b7}\ProgID]

@="RangeUDF.Connect"

[HKEY_CLASSES_ROOT\CLSID\{3c8ed961-b58b-4580-ab67-a45648e2a7b7}\Programmable]

[HKEY_CLASSES_ROOT\CLSID\{3c8ed961-b58b-4580-ab67-a45648e2a7b7}\TypeLib]

@="{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}"

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}]

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}\1.0]

@="RangeUDF"

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}\1.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}\1.0\0\win32]

@="C:\\Temp\\RangeUDF_shimmed\\RangeUDFShim\\Debug\\RangeUDF.tlb"

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}\1.0\FLAGS]

@="0"

[HKEY_CLASSES_ROOT\TypeLib\{917E2CFA-D16C-41b4-BD33-6EE0254C98FD}\1.0\HELPDIR]

@="C:\\Temp\\RangeUDF_shimmed\\RangeUDFShim\\Debug\\"

As you can see, I’m putting the managed assembly, its typelib and the shim all in the same folder and registering them there. Build everything, run Excel and register the automation add-in shim via Tools | Add-ins | Automation, and you’re done.