Advanced Excel Development, Training and Support

Visual Studio Excel Development

latest Visual Studio news

Visual Studio 2005 service pack one was released in November 2006.

This version still requires .net framework 2.0 to be installed on client machines. In Vista .net framework 2.0 is included, combined with some other components and called V3.0.

The recommended approach to worksheet functions is still native win32 XLLs and that still means C++ .

Opinion: .net is still largely irrelevant for most Excel development, including Excel 2007. The next version of Visual Studio (Codename Orcas) may well have some real improvements in this area.

There is much more to working with Excel from Visual Studio than just VSTO. Here's a summary table of the main design patterns and the type of VS project to use.

Here is the powerpoint presentation from the DDD2 community event at Microsoft. The presentation introduces these design patterns and the types of Visual Studio project to use to create each one. It also covered what a COM Shim is and why you need them, and gave some potential reasons to use .net for Excel developments. The VSTO Demo was VS2005RC the COM add-in and the Automation Add-in were VS2003.

COM Add-ins

COM Add-ins are found here:

.net Worksheet Functions

Here is the C# source code for a worksheet function project. You need to create a class library project and swap the contents of that file for this file - cut and paste everything within the namespace is probably the easiest. You then need to set project properties to register for COM interop, and set Excel as the Debug application and run. You will also need to load the addin in Excel by picking it from the list of automation add-ins.

If you want the full gory details of creating your own custom Visual Studio project like this:

then get in touch. Warning - not for novices! If there is enough interest I may create an installation routine - but that's doubtful given the poor performance of .net worksheet functions. This class is based on the work of Eric Carter in Visual Studio Tools for Office, be sure to buy that book (and read it) if you are interested in this area.

.net Worksheet Function Performance

Here is a performance table for a moderately complex array formula I converted to various types of Visual Studio (2003) project:

Here is the worksheet function that was converted (it returns the last non zero value from a list of 100 values):

{=INDEX(B1:B104,MAX(ROW(B4:B104)*(B4:B104<>0)))}

If you would like the full set of projects to play with then let us know. The C++ one was written with the help of XLL+ from Planatech so you will need a demo copy of that. In fact you can download a Zip with an instruction doc, a test workbook, and the VB6 VBA and C# source code here (1.5Mb). You will need Visual Studio 6 for the VB version and 2003 for the C# one (it may work in other versions - let us know).

All the programmed solutions benefited from using a specific algorithm suited to the problem. The performance difference would be quite different for any other problem. The likely outcome being Excel and C++ much closer and VBA/VB6 further behind. C# unfortunately, would probably never make the grade.

The VBA one was compiled, and the IDE closed before running. The VB6 version had all speed optimisations set. I did not bother with a VB.net version as there seems no reason to believe it would be materially faster than C#.

The C# code is significantly different to the other code as it needs an Excel reference to be able to understand the range that is passed in. In VB6 and VBA that is treated as a variant, and looped through in the normal way. However, simply adding 2 doubles (ie no Excel objects) in the above manner takes 30 seconds in C#, so its not just the Excel reference, if at all (Excel comparison time? 0 seconds rounded to 0 decimal places!).

The only fair conclusion from this analysis is that it is very expensive to pass through the Primary Interop assemblies for Office 2003. If a worksheet function is only used a few times then the benefits of .net may outweigh the speed penalty, but for the type of use I see, .net is not currently appropriate. This issue has been raised with Microsoft and they are investigating it.

For now, and probably for a good while into the future, the only viable technology to implement most worksheet functions seems to be C++. And conveniently enough XLL's are also simple to deploy, requiring no registry access, no VB runtimes, and no .net framework. They also work with all versions of Excel from 97 onwards.

And guess what? Codematic can help you write your custom worksheet functions in C++.

We can work from scratch, a paper spec, a complex worksheet function, a VB/VBA function, even old XLM, whatever, we'll convert it to a C++ XLL.

If you require any more information please get in touch.