Hi,
The late-bound reflection-based way that I posted above is nice
because there are no dependencies on interop assemblies and it runs
on .NET 2.0. Given these constraints,
VB.NET would indeed be nicer
since it supports late-binding, which makes calling the COM objects
easier.
If your constraints or environment differs, you might have other
options. C# 4 is as and succinct - I paste the C# 4 dynamic version
below. Also, as I noted, "with a reference to the Primary Interop
Assembly or the NetOffice assemblies it would be a bit neater. "
Some questions that might be relevant to your choices include:
* What version of .NET (or Visual Studio) are you using?
* How will your add-in be used, and what can you install together with
your add-in? Can you assume .NET 4 will be installed?
* What versions of Excel will you be targeting?
The Range property of the Application object _is_ exposed in C#. The
COM object model is exactly the same in all .NET langauges, and is
exactly the COM object model that you might know from VBA.
-Govert
<DnaLibrary RuntimeVersion="v4.0" Language="C#">
<![CDATA[
using ExcelDna.Integration;
public static class RangeTools
{
[ExcelFunction(IsMacroType=true)]
public static object TestReferenceToRangeX()
{
ExcelReference caller =
(ExcelReference)XlCall.Excel(XlCall.xlfCaller);
dynamic callerRange = ReferenceToRange(caller);
return callerRange.Address;
}
private static dynamic ReferenceToRange(ExcelReference xlref)
{
dynamic app = ExcelDnaUtil.Application;
return app.Range[XlCall.Excel(XlCall.xlfReftext, xlref,
true)];
}
}
]]>
</DnaLibrary>