Technology choice

Following on from the recent post about who is the host I have a specific question.

I have an Excel add-in that I want to distribute. I can write it in any of the available technologies, and I am familiar with many of the issues around how to choose (there is some stuff on codematic about that). So without going into the minituae of how and when to choose XLLs over VBA for example my question is this:

Should I

  1. write my app in VS2005 C# using framework 2.0, and be a part of the ecosystem that is driving more broad adoption of this framework?
  2. Or write it in VS2003 against framework 1.1 because this is more widely distributed
  3. Or write it in VBA or as an xll as these have no deployment pre-reqs?
  4. COM add-in in VB6 maybe?(I know people with quite lucrative VB6 add-in businesses, even though it is approaching retirement)

I find myself in a catch 22. I would prefer to use C#2005, but I am concerned that the low penetration of framework 2.0 in my target large corporations will lose me customers. If I use 2005 then I may assist in the uptake and thus improve prospects for this technology longer term. In terms of the functionality of the product lets assume it doesn’t matter at all. I do believe that my target audience will be highly controlled environments, probably slow adopters. I remain unconvinced my product would have the power to drive installation of  a new .net framework.

Of course the big fly in the ointment is framework 3.5 (VS2008) which may be released before my product, thus fragmenting the market even further.

So what would your advice be from a purely business perspective?

I keep coming back to 3, even though I want to play my part in the ecosystem. Maybe I need to forget desktop and client development and jump on the server, software as a service band wagon, at that point there .net starts to make sense.

Anyone got an Office/.net product out there?



11 Responses to “Technology choice”

  1. Marcus Says:

    Hi Simon,

    Hmmm. I’m also developing an add-in product. It’s a reporting tool (should I be telling you this? :P)

    You’ve flagged C# 2005 as your preferred environment, so I’m guessing that performance isn’t a critical factor, nor that the add-in is computationally intensive. I’d contend that you’d only assist in the (.Net framework) uptake if the solution was compelling enough for customers to do so. Again it’s ROI – is there a similar solution out there for which I (the customer) don’t have to have .Net x.x installed?

    I’m currently developing an add-in product in VB6. I also didn’t feel the uptake of .Net was broad enough (there were also concerns about performance and IP security).

    I also looked at Delphi but chose to stick to VB6 with which I was comfortable. I didn’t want to risk developing a distributable product in an unfamiliar environment and didn’t have the luxury of time to work on a few projects to gain that comfort level.

    VB6 provided several characteristics I liked:

    1) A COM Add-in will function in any organization with MSO 2000 and up. A broad a market as I can hope to expect.

    2) Performance is acceptable for the add-in’s purpose.

    3) I’m keeping the solution tiered, so if I later choose to migrate to .Net (or Delphi), the business logic has been kept separate from the GUI.

    4) The customer wont care what language the add-in was developed in provided it does what I’ve claimed and it looks pretty. Deployment issues (such as .net installation) may hinder uptake of the add-in.

    5) I’m not overly concerned about MS support of VB6. The VB6 runtime is built into Vista which should add a few more years to the add-in’s life. And COM isn’t going away anytime soon.

    I shied away from an XLA primary for code security issues. And for customers who are more technically savvy – would an xla come across as amateurish?

    Also VB6 offers so much more in forms development (I’m a big fan of custom user controls). And considering I don’t code in C++ that ruled out an XLL – I considered the learning curve too steep to meet my immediate needs.

    For your needs though it’s difficult to make a call without knowing more about the nature of the add-in.
    > What benefit would C# 2005 offer over the alternatives that was a perceivable benefit to the customer over the others.

    > Could you mix VBA and C++, using an xla for the GUI component (if there is one) and C++ for the logic? This would still have a minimal installation footprint.

    “jump on the server, software as a service band wagon”
    Would the need to involved the IT department hinder uptake of your solution?

    Let us know how your thought process pans out – it’s interesting to see how others tackle the same issues. I also find this – the business side of MSO add-ins – and interesting area. MS do too considering their effort in the Microsoft Office Marketplace – which is one place I intended to promote my offering. Anyone else?

    Cheers – Marcus

  2. Dennis Wallentin Says:


    If You want to protect the intellectual property then XLA is not an option.

    VS 2003 and Framework 1.1 is old and outdated compared with VS 2005 and version 2.0, 3.0 and 3.5 of the Framework. There are some major important updates like security so going with VS 2003 should not be an option for You.

    For the last two weeks or so there has been an “interesting” situation for me:

    A recent security update of VS 2005 made all my VSTO solutions to stop working. I was forced to reset the CAS for them.

    A recent patch update for Windows Vista made my major managed COM add-ins to no longer work. At present I don’t know why and it’s a blackbox scenario to me.

    What can be considered as remarkable is the fact that my VB6 COM add-ins works as expected and also with Vista.

    When it comes to .NET You need to consider how to deal with the PIAs, which are Excel version specific.

    I leave it upto You and other who reads this post to make the conclusions of the above.

    Kind regards,

  3. Ross Says:

    PIA’s, well I think Mike and Dennis have discussed in depth some approaches to that issue on Dennis Blog – interesting reading I recall.

    I would go for VB6.

    Really I would like to say XLL, but if there is a UI involved then I don’t think I could justify the dev time to write it up in C++ (not that I could anyway!) maybe use a XLL if I need some functions, but I think VB6 makes the most sense.

    For now I would stay well, well, well away from VSTO and VS managed com, Dennis’s stories worry us all I’m sure.

    I have tried a few managed com addins, and found them to be (understandable) very slow. I found that making the code com visible and loading it as a library was quicker, but I was not able to isolate this way.

    Still, “You can’t go wrong with VB6” [TM]

  4. gobansaor Says:

    There is a saying in golf world “Drive for show, putt for dough”. In this case I’d say “VS/VSTO for show, VBA/VB6 for dough”.


  5. Simon Says:

    Thanks for the input folks.
    Glad to see a few of us in the same boat. I deliberately tried to steer the discussion away from choosing based on technology, to choosing based on business. I know the tech is important, I’m just struggling to come up with a business driver to adopt .net.
    Dennis your experiences in particular scare me.
    I could certainly do a combination as you suggest Marcus, or maybe pure VB6 as Ross suggests. I was planning to do the intensive stuff in a c dll/xll either way.
    Tom, I like your saying, and sadly I think it rings true. Which leads me back to my point about contributing to the ecosystem.
    All your advice basically advises against an aproach that ‘might’ drive framework installations.
    To me this seems to suggest the ecosystem is breaking down. would you agree?, and why might that be?
    [ps current thoughts are thin UI in VB6 (not C# anymore!), logic in c xlls/dlls]
    Has anyone tried RealBasic?

  6. Stephane Rodriguez Says:

    Aside from steering away from .NET, which when used in a mixed environment is troubles on top of troubles, I would suggest the virtual machine alternative. Preconfigured virtual machines are really the way to go now.

  7. Dennis Wallentin Says:

    I would agree on that the eco system is breaking down.
    Mainly because:
    We experience a major paradigm shift by the Redmont group. High pace for releasing new versions of all softwares together with the fact that today’s issues are not on their agenda.

    I’ve been using vmWare for the last 3 years and the hour it saves me is well beyond the price for a license, disks and RAM.

    Kind regards,

  8. Stephane Rodriguez Says:


    I take it for granted that anybody doing serious development/debugging/testing does use all sorts of virtual machines. But I want to make sure to get my point across : what I am talking about here is actual virtual machine copied onto customer’s client machines. I don’t see where is the drawback when 1) you can use all the fancy programming languages you like, it just does not matter 2) your customer copies a file (a couple gigs), and boom the VM player starts and the customer works with your software without having to worry about anything.

  9. Stephane Rodriguez Says:

    “High pace for releasing new versions of all softwares together with the fact that today’s issues are not on their agenda.”

    Agreed. In fact, many of my customers are people who are not getting served anymore by Microsoft software, only because they use old Windows versions, old Office versions, or old programming environments (one of my products has a developer audience).

  10. Simon Says:

    ‘Todays issues are not on their agenda’ – I think you are completely correct there Dennis, Excellent point, well made!

    I also think tomorrows issues are not on their agenda, they are looking years ahead and completely out of touch with the majority of their customers. I find that worrying.

  11. Dennis Wallentin Says:


    >>But I want to make sure to get my point across : what I am talking
    >>about here is actual virtual machine copied onto customer’s client
    >> machines.

    That’s a very interesting approach and an exellent idea! So far I have only view it from the developing side and virtualized servers. This is something I will take a closer look into.

    Kind regards,

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: