I should add however, some problems with .NET and Excel:
(1) It is slower, period. The interop stands between your code and Excel. So the usual tricks about copying a Range to an Array then manipulating the Array and then passing back the results (instead of looping and editing cell-by-cell) are at even more of a premium. For the most part it is acceptible, but there is a cost. However, from time-testing that Ive seen done from others, user-defined functions can run up to 10x slower, which is very noticable. I would therefore not use .NET if you are making a library of worksheet functions.
(2) Backwards compatibility from Excel 97 through 2003 can be much harder if using .NET. Excel 2002 has PIAs available for download. Excel 2003 has them installed by default (generally). But Excel 2000 and Excel 97 dont have PIAs, so you can install them yourself, or ignore the issue and let .NET create local PIAs for you (which is what I do, and it should be fine, but Ive never tried to deploy a solution using a local PIA).
(3) As I mentioned above, deployment is harder. No harder than .NET is on its own, but it is a different scenario than COM DLLs.
Overall, I would start with a VERY small project and then hit your minimum deployment needs with it. In other words, start with a program that has one button and when you click it, puts the word "Hello" in cell A1 of the Active Sheet. Thats it.
From there, get this working in all versions that you need (which is easiest if you only need Excel 2002 and higher) and try deploying it to a few client machines. I expect that youll hit a few snags even doing this. However, once you get these minimal deployment needs working then youll be able to program it pretty much just as you did with VB 6.0...
Just my 2c!
Mike
