Can .net ever catch up?

Or should that be can it even keep up?

Everyday more and more lines of VBA code are getting written. Organisations are investing more and more in VBA. The potential wrench from moving off VBA is getting bigger and bigger.

There are more and more Excel VBA dev jobs on Jobserve everyday, and the rates are getting better, and the requirements are getting more realistic. .net dev on the other hand, still now after 7 years and 4 versions, is still a drop in the ocean of office dev. Maybe VSTO 2008 will fix that, I’m not convinced are you?

It seems to me that the migration from VBA to .net is not getting easier for most orgs, as they continue to develop in VBA.

Rate of change

Even though much of stuff is getting more usable with each version, I wonder if its too little too late?

What do you think?



17 Responses to “Can .net ever catch up?”

  1. Harlan Grove Says:

    I dunno.

    .Net has the presumed advantage that it’s language neutral, at least among .Net languages. I doubt I’m the only person who writes VBA but doesn’t like BASIC as a language.

    This may boil down to whether SharePoint becomes the biggest fish in the Office ocean. From my perspective working for a company that’s committed for the mdeium term to Lotus Notes, SharePoint isn’t going to matter to me for years. OTOH, companies using Microsoft server software including SharePoint are obliged to use .Net/managed code, aren’t they?

    Platform will determine the VBA vs .Net issue since it doesn’t appear VBA will ever be part of SharePoint/Excel Services.

  2. Stephane Rodriguez Says:

    .NET is a confusing brand. Under the same umbrella you have the Silverlight version, 1MB, and the .NET 3.5 version whose redist is 197 MB.

    To add matters, Microsoft failed to come up with a proper Java rip off. Microsoft indeed did rip off Java, that’s what .NET originates from (in fact all .NET guys where working in the Java, Visual J++ team back in the middle 90s). What does it mean?

    – the virtual machine failure to be a real abstraction. Microsoft’s fear that the virtual machine could run outside Windows, therefore killing one of the two cash cows, has caused a number of engineering and design decisions over this “Windows-optimized” virtual machine now known as .NET. In fact, those decisions were so bad that you have a 32-bit version of the virtual machine, and a separate 64-bit version even though the whole point of the virtual machine is to abstract this away. This is just as bad as the lack of Office 64-bit edition.

    – the .NET loader, which instead of working on its own rules, simply enforces both native and .NET rules, which makes it virtually impossible to deploy reliably. Take a look at Andrew Whitechapel’s blog these days, what they are doing to improve VSTO and related stuff is still to fill the same holes than 5 years ago. It was a bad decision not to have a .NET loader getting rid of anything native, and everyone is paying the price every single day.

    The issue could be mitigated (*), but what are the odds that Microsoft fixes it at the expense of their bottom line?

    (*) : create a new .NET embedded run-time environment that is part of Excel (and other applications). Make it possible to run and debug code without deployment hassles (i.e. code is embedded in the files)

  3. Johan Nordberg Says:

    Acutally it’s five versions. ;)

    Are you talking about .net in Office or .net in general? is really big. I don’t have any numbers, but it’s biiig.

    Stephane: Are you talking about like the way VSTA is used in InfoPath? I think that is the perfect fit between real .net apps and vba. You have the power of the .net languages, but without much of the frustration of vsto. I haven’t tried to deploy any .net infopath solutions yet and don’t know much about that, but deployment isn’t that hard once you know how. (But compared to vba it’s a pain in the butt…. But what deployment isn’t? Even a VB6 Com Addin is much worse than plain old vba.)

  4. Simon Says:

    Harlan good point about the sp effect, and I’m with you on the language thing (see next post).

    Stephane, I looked at J++ way back – couldn’t see the point, interesting point on VMs, must be a hard choice as a platform vendor. re embedded I take it you don’t mean like SQL 2005? I agree the code needs to be in the file.

    Johan client, always client. I am only interested in client side/desktop/smart client development. I know server side exists, I know it has value, but currently it holds little interest for me.
    I was thinking VS2002(1.0), 2003(1.1), 2005(2.0), 2008(2.5/3.0), what did I miss?
    deployment: VBA v rest of world – spot on (see next post), this is why those technologies have never caught on for Excel dev.

  5. Dennis Wallentin Says:


    When large corporates make their moves present investments tend to have the value of 0. It’s called strategical decisions.

    In addition, progress means that technologies that was considered as new yesterday are de facto standards today.

    For me it’s not a question of VBA vs .NET it’s more a question of which toolset to use for different tasks.

    Kind regards,

  6. Martin Rushton Says:

    “When large corporates make their moves present investments tend to have the value of 0. It’s called strategical decisions.”

    In accountancy it is called sunk costs and it is one of the cornerstones of accounting. What you have spent is irrelevant when making future decisions (other than that money isn’t available to spend). I don’t particulalry like the concept as it allows manager’s to absolve themselves of responsibility for some horrendous past decisions.

  7. Simon Says:

    Costs can be sunk costs alright, investments though have a value, and they are recorded as assets, the capital expenditure of acquisition is amortised over the value bearing life.

    Strategically, yes for sure many orgs are moving to/have moved to .net as the strategic platform (C# most commonly). Tactically though at the sharp end finance folks are still churning out tons and tons of VBA.

    The post wasn’t about VBA v .net, it was highlighting the increasing challenges for VBA’s replacement, which has been suggested to be VSTA/VSTO.

    I totally agree on selecting the most appropriate toolset for the job in hand, weighing all valid considerations. (and then choosing what will look best on the cv right? ;-))

  8. Dennis Wallentin Says:


    Thanks for reminding me what it’s called in English cost accounting, i e sunk costs.

    Let’s see what the impact will be of SharePoint Server and Excel services within the nearest future.

    (Of course, the more lines of .NET in the CV the higher rate ;-) )

    Kind regards,

  9. Mike Staunton Says:

    I teach and write code in the financial derivatives area where everyone has Excel and VBA is used pretty widely, sometimes just for prototyping with production code in C++

    So I have been trying to live in both VBA and .net worlds with the following restrictions: write only UDFs in VBA with no use of Excel functions (yes it’s sometimes a bore duplicating Excel functions myself but some of them such as NORMSDIST are not accurate enough for my purpose anyway)

    I use only the .net Math functions so from my VBA code I then have to do some search and replace to get from Sqr to Sqrt and the like and create my own Int function as well as handling complex number calculations)

    Having done this, I can create XLLs with ExcelDna or an equivalent commercial product as well as automatically translating code into C++ or C# using Instant C# from Tangible Software

    I avoid the VS IDE though others can use the free Express editions though do need to have the .net framework for ExcelDna to work – but no other .net files

    If MS really wants to migrate people away from VBA in Office, it will have to make it a lot, lot easier than at present – and get away from unconvincing and over-complicated attempts such as the VSTO for mere mortals book

    MS developers will want to stress how wonderful .net is but until they seriously address the rest of us with tens of thousands of lines of legacy VBA code, they’re wasting their time

    PS just bought a new PC to discover that my ADSL modem won’t work with Vista – but I did make sure that I copied over my copy of Excel 95 just in case!

  10. Simon Says:

    Dennis, yes I’m really interested to see the impact of those.

    re rates – that may be the way to migrate VBA devs. They may have poor taste in syntax, but they understand money. If .net rates were consistently double VBA there would be a stampede. Well 2 actually – devs pouring into .net and budget holders pushing for VBA.

    Mike sorry to hear the Vista hassles, should have gone Linux, same driver hassles, but copies faster.

  11. Johan Nordberg Says:

    Simon: 1.0, 1.1, 2.0, 3.0 and 3.5. :)

    3.0 shipped with Vista and 3.5 with VS 2008.

  12. Johan Nordberg Says:

    Mike: Why do you need driver for a DSL modem? Dont you just plugin the ethernet cable in the modem? I’ve never had a DSL modem or router that requires OS drivers.

  13. Simon Says:

    Good point Johan I just plug an RJ45 in, oh hang on thats a router. modems are usually USB devices. ISP’s give them with subscriptions because they are too tight to give away router/firewalls.

  14. sam Says:

    What bugs me the most …and I have said this earlier is the fact that MS considers Office as a Development platform and yet stops the Developer version of office from 2003 onward…..

    Wouldnt life be simple if we could create a XLL/DLL simple by saying File-SaveAs Type – XLL/DLL….

    If this could be done would we really need VSTO/VSTA/.net…..Blah…Blah….Blah….

  15. Simon Says:

    Its hard to believe they genuinely see it as a dev platform, what with the new fuckwit interface an all.

  16. Stephane Rodriguez Says:

    How timely, Scott Guthrie is annoucing a new .NET update…

    We need more binaries to worry about.

    And guess what, for the 469th time, they are making changes to the bootstrap, MSI and loader to fix the deployment issues .NET developers are having.

    So you can take for granted that .NET deployment is FIXED NOW. Well, until the 470th fix…

    Of course, I’m playing devil’s advocate. The real message is that Microsoft has once again screwed up with .NET and are admitting to be unable to make it possible to deploy .NET reliably.

    This is not to say that .NET cannot be used in any scenario, of course. But when you know this, it explains why Microsoft can’t seem to be able to replace VBA faster than they want.

  17. Stephane Rodriguez Says:

    Deploying .NET 3.5 on Windows Vista :


    Sounds like a nuclear plant getting out of control.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: