@SinisterSlay -

Actually, you *can* load the Excel DLLs and program against them. It's just a really bad idea in many scenarios. The biggest problem is with server side stuff... do you really want to shove Excel into memory anytime someone hits that page (especially if it's a common page)? And there have been all sorts of performance problems. For example, running it as a server app forces Windows to load a desktop session, but each desktop session never gets exited, and each request creates a new desktop session, causing a memory leak.

@gskur -

I understand where you are coming from about VBA being the "only" tool for automatic Excel. Except, that's incorrect. If you are talking about pure, in app automation, it's right. But there are plenty of ways to manipulate Office applications. You can use the Visual Studio Tools for Office (VSTO) package, for example. There are a number of libraries to manipulate Office documents without starting the associated application. You can have a small VBA application bootstrap another application to do the real work.

In other words, there is no mandate at all to use VBA. It sounds like we all agree that it's not a good language, and in a lot of scenarios, using it makes sense despite it's issues (I made my living like that for a while). But it's not the only way to work with Office, thankfully.

J.Ja