Hi Attila,
Calling the Excel automation object model late-bound from C# is the
most cumbersome way to do it.
VB.NET is much better than C# for this,
although C# 4 is a great improvement. The nicer-looking C# example
uses .NET 4 and the 'dynamic' type, and is at is Distribution\Samples
\DynamicMethodSample.dna.
All other ways I suggested in my first reply are more elegant than C#
late-bound via reflection. Which of those alternatives are best for
you depends on what tools you are using, what you know and who will be
using your add-in. For just getting started, if you definitely want to
use C# instead of
VB.NET, I'd suggest you install the Primary Interop
Assemblies (PIAs) for your Office version (download from Microsoft,
and add a reference in your project). Then you don't need the late-
bound reflection-based InvokeMember stuff, and your code will look
like the VB code.
ExcelDnaUtil.Application is just a way of getting the the correct
Excel Application object from within your add in. The returned COM
object is the same object you would have in VBA when you put in
'Application', and is your entry point from Excel-DNA into the Excel
COM object model. The Application object is the entry into a huge
library that is part of Excel and not part of or particular to Excel-
DNA. Some documentation entry points are here:
http://msdn.microsoft.com/en-us/library/wss56bz7(v=VS.100).aspx, and
http://msdn.microsoft.com/en-us/library/aa168292(v=office.11).aspx.
The object model used from Excel-DNA via C# or
VB.NET is the same
object model used from VBA, so all those VB examples should be fairly
easy to translate once you get the hang of it.
If you have never worked with Excel programming, you'll have to get
used to translating those VBA examples to .NET. Certainly
VB.NET is a
bit easier than C#, but the object model you're coding against is the
same.
-Govert