Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h03/mnt/25679/domains/ on line 36

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h03/mnt/25679/domains/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c02/h03/mnt/25679/domains/ on line 507
2007 September
Sep 27

Well, here it is. First post. If you’ve followed my first blog, you already know that I’m a bit of an Office Zealot. Truth of the matter is that I’ve always been more of an Excel zealot rather than an Office zealot. Yeah - I can get around the Outlook object model; sure - Word is okay; yep - SharePoint is the future. Frankly, I’ve never been that enthused about anything else besides Excel.

Why is that? I’d have to say Excel fits my personality. I enjoy analyzing things as evidenced by acquiring an MBA with a concentration in finance, working as a financial analyst for several years (and analyst starts with anal you know), and making a living the past decade as a consultant analyzing other peoples problems and developing systems to help solve them. Excel is very natural to me (except for this bug that is - I find it very unnatural).

OK, so where am I going with this. Oh yeah - while this is a VSTO blog - it will be more of an Excel VSTO blog, occassionally litered with Outlook, Word, and SharePoint posts. Also this blog will be as much about .NET Excel development as it will be about VSTO.

To clarify this statement requires a little background in to just what VSTO is and how it works. In a nutshell VSTO is a toolset that allows you to automate Excel using managed .NET code. Excel however is a COM based (un-managed) application. When it comes to Excel development, .NET and COM seem to go together like a peanut butter and pickle sandwhich. If that were the end of things that’d be a big enough hurdle to worry about. But it gets weirder…

You see, in order to have a COM based application work with .NET code, you need a layer of software in between the two called an interop. The Office team at Microsoft is responsible for creating the primary interop assembly (PIA) for Excel. The VSTO team at Microsoft reports up through an entirely different division at Microsoft - the Visual Studio team. The problem with this arrangement is that VSTO is entirely dependant on the Excel PIA. Since VSTO isn’t in the same line of reporting, they don’t explicitly have any power to affect change on the Office side of the fence. How this affects you is that as someone trying to learn how to use VSTO, much of the frustation you’ll encounter is due to the oddities of the Excel PIA, rather than functionality provided by VSTO.

Further compounding this issue is that these PIAs aren’t documented sufficiently and that as much as the VSTO team would like you to use VSTO, they are a bit powerless to document the PIAs (the “not my problem” and/or “not my budget” syndrome). If you post problems to the VSTO forum you’ll occasionally run up against this line of thought. Anyway, to wrap this point up, as far as this blog is concerned PIAs are “covered” under my definition of VSTO.