Nov 30, 2011 at 3:35 PM
Edited Nov 30, 2011 at 3:36 PM
I have a specific use case where I have two ExcelDNA addins that share common functionality. My technique thus far has been to create abstract base classes in a common dll, which are then extended by each addin separately. This works great for abstract implementations
of IRtdServer and IExcelAddin (because they are just interfaces). However the ExcelRibbon class resists this paradigm because of the following code in AssemblyLoader.cs (line 149):
bool isRibbon = (t.BaseType == typeof(ExcelRibbon));
My AbstractRibbon class passes this test, but the concrete subclass does not because its "BaseType" is AbstractRibbon, not ExcelRibbon.
Can I suggest this be changed to:
bool isRibbon = t.IsSubclassOf(typeof(ExcelRibbon));
This seems more reasonable to me since it really should not matter whether a ribbon directly extends ExcelRibbon or not. If we want to be even more thorough, we can add:
bool isRibbon = t.IsSubclassOf(typeof(ExcelRibbon)) && !t.IsAbstract;
(This way we avoid the exception when invoking Activator.CreateInstance(t) on line 159).
Hope this is helpful in creating a more robust framework!