In my last post I explained reasons and gotchas to be concerned with when deciding to migrate from an Excel *.xla add-in to a C# add in.  One of the reasons revolved around not having an easy way to use a source control product (we use Visual SourceSafe) to manage the actual code files of a VBAProject.  This is because the *.xla is a binary file and using SourceSafe (and I would assume other products) you can not compare differences of a binary file (not to mention the VBAProject files that are part of the binary blob).

I mentioned that I automated getting the code files out of the VBAProject and into SourceSafe.  I am sure there third party add-ins that allow a source control product to integrate into Excel, but the code is fairly simple to automate it yourself.... [More]

At my day job, we use Microsoft Excel spreadsheets as a pseudo "specification document" (spec sheet) for the websites, which are actuarial in nature, we create.  At the time (several years back), since we chose Excel, obviously we needed an add-in for the few automated processes we supported and we needed something immediately (you know how it goes in small companies).  The easiest way for us to create the add-in we needed was to create an Excel add-in file (*.xla).  My background (5-6 years ago) was from VB6 anyway, so even though I'd switched to C#, VB6 was still fresh in my mind and writing VBA was a breeze - whether the code was clean or not, I've got not comment ;).  I've recently made the decision to migrate an existing Microsoft Excel Add-In (*.xla) file to managed C# code.  There were several motivating factors to this decision along with almost as many speed bumps... [More]