Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

.NET and Office/VBA

We have a number of fairly sophisticated Excel/VBA applications (don't get me started) and are interested in .NET but cannot determine what is the best way to move to .NET given this code base. What are the plans for .NET support in Office applications? Will VBA be replaced? Is the solution to use the COM/.NET integration? Has this important piece of Microsoft's development platform been overlooked?

David Avraamides
Thursday, September 19, 2002

COM Interop actually works quite well.  I have written some small apps that automate Excel and Word via this interface quite effectively. 

They don't replace VBA since they don't run in the environment and/or serialize into a document however.

Chris

Chris Kinsman
Thursday, September 19, 2002

The Microsoft Developer Tools Roadmap for 2002-2004 [1] mentions the Office and .NET integration plans.

[1] http://msdn.microsoft.com/vstudio/productinfo/roadmap.asp

Bernard Vander Beken
Thursday, September 19, 2002

Microsoft's announcements, few as they are, make it clear that you will not be able to write managed code in Office applications in the immediate future. For any near-term (1-2 years) development, your choices are to use interop, or to use Web Services (which Office apps can consume), or to not have Office play with .NET code.

I don't think it's so much a matter of having neglected this part of the product line as the fact that getting managed code into Office without breaking backwards compatability with VBA is going to require massive rearchitecting.

Mike Gunderloy
Friday, September 20, 2002

You may want to look at

Working with the Office XP Primary Interop Assemblies

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_piaissues.asp 

I think it has more to do with .NET Apps interoperating with Office apps, but worth checking out.  It deals with PIA's  - here is a snip

While any number of COM interop assemblies may exist, only one COM interop assembly is designated as the primary interop assembly (PIA). The PIA contains the official description of the unmanaged types as defined by the publisher of those unmanaged types. The PIA usually also contains certain customizations that make the types easier to use from managed code. The PIA is always digitally signed by the publisher of the original unmanaged type.

Nick Katsivelos
Sunday, September 29, 2002

Yes, PIAs are for using COM servers from .NET applications. Actually, a PIA is just a Runtime-Callable Wrapper (RCW) - the thunking layer between .NET calls and COM servers - that comes from the vendor of the original COM server.

Mike Gunderloy
Monday, September 30, 2002

Mike,

I think we can agree (tell me if I am wrong) that the issue is that the average person who has worked for years putting together some killer Excel-based app (whose real job is being an HR Supervisor) is not going to take kindly to an upgrade path similar to the one that they laid out for the professional VB developers. I think you are going to see a co-existence approach - like COM & .NET , like ASP & ASP.NET you are going to see some side by side stuff with some interop.

That would be AOK by me.

Nick Katsivelos
Monday, September 30, 2002

*  Recent Topics

*  Fog Creek Home