govert
commented
3 months ago Hi @jmkinzer - we've already implemented step 1 with the optional machine hive check (only when running as admin) for the next version 1.8.0. Maybe you can try the current pre-release version 1.8.0-alpha3 and confirm that it works right for you.
Step 2 is a bit more tricky - It can be done with the current library, but you need to configure the ribbon a bit differently:
- Set up the project with the ribbon to not load automatically, but instead be published with Excel-DNA as a 'ComServer'.
- Call regsvr32 to register the COM class
- Add the required registry entries to Excel for the ribbon ProgId to be a known COM AddIn
- 'Connect' the ComAddIn when the add-in is loaded
Each of these needs a bit more explanation. I've published a test add-in with the below code here https://github.com/govert/TestRibbonRegistration but you have to do the registration steps yourself.
- In the project file, you need a property to indicate you will by exposing types as COM classes through the Excel-DNA .xll add-in:
<ExcelAddInComServer>true</ExcelAddInComServer>
Then your ribbon class would not derive from ExcelRibbon as usual, but instead just be an ExcelComAddIn which implements IRibbonExtensibility explicitly:
using System;
using System.Runtime.InteropServices;
using ExcelDna.Integration;
using ExcelDna.Integration.CustomUI;
using Microsoft.Office.Interop.Excel;
namespace TestRibbonRegistration
{
internal class ComConstants
{
// Choose your own ProgId and a new Guid here
public const string RibbonProgId = "TestRibbonRegistration.MyCustomRibbon";
public const string RibbonGuid = "E595901B-903E-4FE7-8D06-6E7F3D5A2C4F";
// This is the Guid for the IRibbonExtensibility interface - don't change this
public const string IRibbonExtensibilityGuid = "000C0396-0000-0000-C000-000000000046";
}
[ComVisible(true)]
[ComImport]
[Guid(ComConstants.IRibbonExtensibilityGuid)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
internal interface IRibbonExtensibility
{
[DispId(1)]
string GetCustomUI(string RibbonID);
}
[ProgId(ComConstants.RibbonProgId)]
[Guid(ComConstants.RibbonGuid)]
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDispatch)]
public class MyCustomRibbon : ExcelComAddIn, IRibbonExtensibility
{
public string GetCustomUI(string RibbonID)
{
return
@"<customUI xmlns='http://schemas.microsoft.com/office/2006/01/customui'>
<ribbon>
<tabs>
<tab id='tab1' label='My Tab' >
<group id='group1' label='My Group'>
<button id='button1' label='My Button' onAction='OnButtonPressed' />
</group >
</tab>
</tabs>
</ribbon>
</customUI>";
}
public void OnButtonPressed(IRibbonControl control)
{
var app = (Application)ExcelDnaUtil.Application;
app.StatusBar = "Button Pressed!";
}
}
}- In your installer you would need to call "regsvr32 MyAddIn.xll" or "regsvr32 MyAddIn64.xll" or do the equivalent. This calls the
DllRegisterServer()export of the x.ll add-in, which writes (to the user hive) the PorgId / ClsId etc. registration for the COM classes exposed by the add-in (i.e. the MyCustomRibbon class). It registers the .xll file as the 'InProcServer32' so this is quite different from the usual COM registration for .NET classes (which use mscoree.dll as the server).
In my test I just run from a (non-admin) command line:
PS C:\Temp\TestRibbonRegistration\bin\Debug\net472> regsvr32 .\TestRibbonRegistration-AddIn64.xll- Your installer will then need to add the ProgId as a known COM Add-In to the Excel part of the registry. To the key
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Excel\Addinsyou add a new key with the ProgId name, and I think at least the LoadBehavior value. The Description and FriendlyName are optional, and appear in the Excel dialog boxes.
- Loading the ribbon when your .xll add-in loads can now be done from an AutoOpen() handler, though you still need to take some care. You should avoid doing it directly in the
AutoOpenbut instead run as a macro after initialization.
using ExcelDna.Integration;
using Microsoft.Office.Core;
using Microsoft.Office.Interop.Excel;
namespace TestRibbonRegistration
{
public class AddIn : IExcelAddIn
{
public void AutoOpen()
{
// It's better if we don't load other add-ins during the AutoOpen method
// So we schedule the ribbon load to run after the add-in is initialized,
// when Excel is idle again.
ExcelAsyncUtil.QueueAsMacro(() => RegisterRibbon());
}
public void AutoClose()
{
}
public void RegisterRibbon()
{
var app = (Application)ExcelDnaUtil.Application;
var progId = ComAPI.RibbonProgId;
// Enumerate the registered add-ins, and load the one with the right ProgId
foreach (COMAddIn addIn in app.COMAddIns)
{
if (addIn.ProgId == progId)
{
addIn.Connect = true;
break;
}
}
}
}
}
jmkinzer
The ribbon portion of the addin causes excel to crash on various corporate machine running 365. It's related to the ribbon registration although it's hard to say what the root-cause is (after monkeying around the error tends to vanish and then cannot be re-introduced). I believe this suggestion however is along the lines need to resolve it: https://github.com/Excel-DNA/ExcelDna/issues/317#issuecomment-1525390378
These two steps would probably prevent any possible problems here: