why excel vba != .NET?

Slightly with the question of how commited is MSFT to .NET, what is the reason for excel not having a VBA based on .NET? Is there a new office beyond 2010?  Does it have a better automation story than the prior versions?  Please correct my understanding of Excel automation, but I find VBA simply terrible to use. And considering the number of business people who use excel it seems like a great waste of programming possibilities.

Because nobody wants to re-write all of those crufty Excel macros in .Net?

Because MS decided that distributing executable code in a document file was perhaps a bad idea security wise and decided to go with a different model with VSTO.

Because there is VSTO.

Because HTML5 and JavaScript are the new hotness, therefore there is also "Apps for Office 2013".

@SteveRichter: I don't really have a problem with VBA. It's extremely similar to VB6, which is one of the most popular Windows programming platforms even today.

MS leaves it in there for backwards compatibility. Look at VSTO/Apps for Office 2013 for new projects.

1 minute ago, DCMonkey wrote

Because MS decided that distributing executable code in a document file was perhaps a bad idea security wise and decided to go with a different model with VSTO.

 

I don't follow why there cannot be a sandbox framework that would limit which methods, classes and assemblies could be used from a VBA.NET.

3 minutes ago, spivonious wrote

MS leaves it in there for backwards compatibility. Look at VSTO/Apps for Office 2013 for new projects.

my only problem with VSTO is it seems to take programming away from the end user. But I should learn it.

They are still making their own C# Interpreted Language I suppose.

VBA wouldn't be too bad if the IDE wasn't still exactly the way it was in VB6 (even in Office 2013).

Certain behaviors, like the modal dialog for a syntax error whenever you move your cursor away from a line that has an error on it, are just extremely annoying. Another pet peeve is the way the editor capitalizes names based on declarations. If I declare a variable named "width" (without capitals), then any reference to e.g. a property named Width in the same function will automatically be cased like my variable rather than the proper casing for the property. Since VBA is case-insensitive it doesn't affect functionality, but it looks messy.

The editor's UI also looks really incongruous in recent versions of Office.

VSTO and stuff are nice, but if I quickly need to move all graphs ten points to the left or something, it's much easier to quickly write some one-time-use code in VBA, so I'd really appreciate it if they gave the editor some love.

@SteveRichter: VBA exists now solely for backwards compatibility. It's a horrendously crufty language, with almost as many quirks as the actual Office Object Model itself. VSTO was an attempt to somewhat modernize things by encouraging people who were currently building horribly overcomplicated applications in VBA (I know this pain, I have to work on one from time to time!) to something closer to .NET development, but it never really took off fully. I think that is not insignificantly down to the fact the Office automation is horribly flaky, so it's borderline impossible to actually build a robust solution on it, regardless of the language.

The new kid on the block is the Javascript-based Office plug in app things. They're a little more constrained in what they can theoretically do, but they should at least work in a reliable way (and transistion to an Office 365 arrangement rather more seamlessly).

You need to get your history right.

VBA existed in Excel long before .NET even existed.

12 hours ago, Sven Groot wrote

VBA wouldn't be too bad if the IDE wasn't still exactly the way it was in VB6 (even in Office 2013).

Certain behaviors, like the modal dialog for a syntax error whenever you move your cursor away from a line that has an error on it, are just extremely annoying. Another pet peeve is the way the editor capitalizes names based on declarations. If I declare a variable named "width" (without capitals), then any reference to e.g. a property named Width in the same function will automatically be cased like my variable rather than the proper casing for the property. Since VBA is case-insensitive it doesn't affect functionality, but it looks messy.

The editor's UI also looks really incongruous in recent versions of Office.

VSTO and stuff are nice, but if I quickly need to move all graphs ten points to the left or something, it's much easier to quickly write some one-time-use code in VBA, so I'd really appreciate it if they gave the editor some love.

You can stop that modal popup by going to Tools->Options and unchecking "Auto Syntax Check". It would be nice if they updated the editor. It's not even up to par with VB6; it's more like VB4's IDE.

3 hours ago, AndyC wrote

@SteveRichter: VBA exists now solely for backwards compatibility. It's a horrendously crufty language, with almost as many quirks as the actual Office Object Model itself. VSTO was an attempt to somewhat modernize things by encouraging people who were currently building horribly overcomplicated applications in VBA (I know this pain, I have to work on one from time to time!) to something closer to .NET development, but it never really took off fully. I think that is not insignificantly down to the fact the Office automation is horribly flaky, so it's borderline impossible to actually build a robust solution on it, regardless of the language.

Yeah, the flakiness is what always killed it for me ... all the Office automation stuff I've built had to include a lot of "if operation foo randomly fails, retry a few times and then try fallback solution XYZ" sort of logic. It felt like a nondeterministic environment, and maybe if I had a deeper understanding it wouldn't anymore, but there never seemed to be any clear path to get one (other than join the Office team and get access to the code ...)