Add-in can not be registered when is launched as administrator using Excel 365 version 16.0.12827.20200

[elarmando]

Hello everyone, I would appreciate a lot your support with this problem.

I've been facing this error when I run the CustomTaskPane example (link to example).

This only happens when I run excel (or visual studio) as administrator. My current excel version is this one:

This is a recent version so I tried to replicate the problem using office professional plus 2016 16.0.4266.1003, but in that version works good.

I'm also concerned about this issue issue but this time the add-in is not disabled by excel.

Thanks a lot.

[govert]

Can you confirm what version of Excel-DNA you are using?

[elarmando]

The problem can be replicated using version 1.0.0

[govert]

@elarmando OK - I'll have to set some way of testing and debugging this. Do you have a ribbon component in your add-in, and does it work in the elevated process? The ribbon loading is a bit different to the control registration for a CTP.

[elarmando]

Yes, I have one and It is not shown either. Thanks a lot for the quick reply, Govert.

[govert]

It this an environment where some Group Policy setting might be in place? There are various Excel, Office and other behind-the-scenes security settings that might be involved.

This is an example: https://groups.google.com/d/topic/exceldna/UaXeax0vHAI/discussion

[elarmando]

Hi, Govert,

The first time I saw the error I was in the company where I work, so I did the same test in my personal computer to avoid some kind of security. The error still appears. According to the link you provided, I checked the registry to find some kind of policy but I didn't find something. I also added the folder of the xll as a trust location, but didn't help.

I hope this information is useful, thank you.

[andysinclair]

Hi,

I have just had this issue reported by one of the users of my Add-in. It works fine in non-admin mode, however if you run Excel (or Visual Studio) in Administrator Mode you don't see the ribbon nor the Add-in. I enabled verbose logging and can see the following error:

[ERR] The Ribbon/COM add-in helper required by add-in ExcelPriceFeed could not be registered.
This may be due to the helper add-in being disabled by Excel.
To repair, open Disabled items in the Options->Add-Ins page and re-enable target add-in, then restart Excel.

Error details: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: Class not registered

   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
   at ExcelDna.Integration.ExcelComAddInHelper.LoadComAddIn(ExcelComAddIn addIn) : TargetInvocationException - Exception has been thrown by the target of an invocation.

Not sure how to investigate/fix this, any ideas?

[govert]

@andysinclair I can reproduce the error you report too, but I haven't been able to debug it or understand whether this is behaviour that has changed in Excel. Is this something that used to work in the same setting for your add-ins (running in an elevated process)?

[andysinclair]

Hi @govert Thanks for the quick reply. I’m afraid this is the first time I have experienced this issue so I can’t say if it ever used to work. I’ll continue to investigate and report back here if I discover anything.

[govert]

@elarmando Is this a scenario that worked before with your add-in? I'm trying to figure out whether the changes relate to an Office or Windows update.

[elarmando]

Hi, @govert , It used to work two weeks ago. I suspect it was an office update.

[govert]

@elarmando @andysinclair I don't really understand the cause, but I have a plan and will try to push a workaround in the next few days.

[elarmando]

Thanks a lot, @govert :)

[andysinclair]

Thanks @govert and do let us know if you need any help testing.

[govert]

@elarmando @andysinclair I've pushed an updated version of Excel-DNA to NuGet as version 1.1.0-beta3. This version has a (small !?) fix that seems to work around this issue.

I would appreciate if you could give it a try, and provide any feedback. I have only checked on my own machine, and not under 64-bit Excel at all.

I don't understand the problem or why the workaround works (just talking to the registry in a slightly different way). However, I can see it relates to how the registry gets virtualised by the Office Click-To-Run infrastructure. This is generally poorly documented, so it's a bit hit and miss.

[elarmando]

Thanks a lot, @govert , I'll test it and let you know if everything works as expected.

[elarmando]

Hi, @govert , I did some test using both excel, for 32 and 64 bits. It is working as expected. A colleague will run an automatic test suite this night just to see if there is any regresion error. I'll let you know our results. I appreciate a lot your help to fix this error so quickly. Thank you

[andysinclair]

Hi @govert I have also tested it and it is working well. I have tested Admin mode Visual Studio and the 32 bit version on another machine, so far so good. I have also sent it to a customer for testing. I will report back here if I notice any issues. Thanks for your help with this.

[elarmando]

Hi, @govert , the fix is done, Thank you so much. Should I close this issue?

[raymondjstone]

Maybe not of help with the issue solved but is this not what 'active setup' is for? I use that to register the addin for new users as they log in when the software it is using is a per machine install.

[govert]

@raymondjstone You're right - Active Setup seems to be the standard way of ensuring per-user installs can be done for all users. With Excel-DNA I've tried to also make it possible to just deploy the add-in file without any extra installers. This works quite well, but the current issue is a surprising one where there were problems when the process is running elevated. That seems to be resolved now.

[govert]

Here is a new report post-v1.1.0 for a related issue: https://groups.google.com/g/exceldna/c/TSOPygt334Y

Not sure if the App-V is a sufficiently different environment, or whether this affects only elevated contexts. But the issue sure seems related:

Some of our users are seeing a problem loading up our ExcelDna add-in. They have been running Excel Office 365 in a virtual manor using AppV successfully for some time. Last week they upgraded to the latest Office and that's when the problem started. They are using DNA version 34. Here's the DNA error log:

ExcelDna.Integration Verbose: 4 : Loading Ribbon/COM Add-In
ExcelDna.Integration Verbose: 4 : RegistrationUtil.CanWriteMachineHive - UnauthorizedAccessException - False
ExcelDna.Integration Error: 4 : RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Illegal operation attempted on a registry key that has been marked for deletion.

ExcelDna.Integration Error: 4 : RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled
ExcelDna.Integration Error: 4 : The Ribbon/COM Add-In helper required by add-in XXX could not be registered.
This may be due to restricted permissions on the HKCU\Software\Classes key : UnauthorizedAccessException - RegistrationUtil - Unable to write to Machine or Users hives of registry

Some other posts to this group discuss this issue I believe. We thought upgrading to DNA version 1.1.0 would fix it. But the problem is still there after the upgrade. Would be grateful for any insights or suggestions.

[rosssaunders]

Hi,

I seem to be have a very similar issue when using DNA 1.1.0 and running Excel 2016 under Click-To-Run. It's in a corporate environment so I'm not sure the exact details of the setup of AppV and whether is a pseudo or real context.

For some background, the add-in exposes several COM objects as well as a custom Ribbon and everything works great under Excel 2010. We are currently migrating to Excel 2016 and are hitting the following (from the logs)

DEBUG ExcelDna.Logging.Logger - ExcelComClassType.RegisterServer ABC.Dept.ComObject - ABC.Dept.ComObject (b5fa9611-931a-4b23-888a-a4f550e4412b) DEBUG ExcelDna.Logging.Logger - DEBUG ExcelDna.Logging.Logger - Loading Ribbon/COM Add-In DEBUG ExcelDna.Logging.Logger - DEBUG ExcelDna.Logging.Logger - RegistrationUtil.CanWriteMachineHive - UnauthorizedAccessException - False ERROR ExcelDna.Logging.Logger - RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - The specified registry key does not exist. ERROR ExcelDna.Logging.Logger - ERROR ExcelDna.Logging.Logger - RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled ERROR ABC.Dept.ExcelAddin - Failed to dynamically register the COM server System.UnauthorizedAccessException: RegistrationUtil - Unable to write to Machine or Users hives of registry at ExcelDna.ComInterop.ComRegistration.RegistrationUtil.get_ClassesRootKey() at ExcelDna.ComInterop.ExcelComClassType.RegisterServer() at ExcelDna.ComInterop.ComServer.DllRegisterServer() at ABC.Dept.ExcelAddin.AutoOpen()

Excel is being run under a standard user (non admin) account and has permissions to write to the "HKEY_CURRENT_USER\Software\Classes" hive, however, by looking into the registry, I can see that this is being virtualized to here "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\USER" which a standard user account does not appear to have the security permissions to write to. I would have hoped that the virtualization layer of AppV would still write to the USERS virtual hive, however, this does not appear to be the case. (Unfortunately due to corporate policy I cannot run Procmon to see what is going on under the hood.)

I saw in the other conversation your comment: "It might be possible to change the parts of your add-in that are loaded using the on-demand COM registration (probably a Ribbon extension) into being pre-registered. That would mean you need to pre-register the add-in on the machine, outside the App-V sandbox. It would take some experimenting to see how this works.". We have VSTO addins that work fine and I'd assume it is because the installation is happening outside of the AppV sandbox.

Do you have any further thoughts on how to start going about pre-registering the COM components using ExcelDNA and where I should start looking?

Thanks v. much in advance for any assistance,

Thanks,

Ross

[govert]

@rosssaunders I can't remember all the details, but I think that the registry write is to HKLM...\ClickToRun\REGISTRY\USER is normal, and we expect the user to have permissions to write to that key. But I'd have to get back into the details again - not so easy every time, as you might imagine.

It would be a big help for me to have access to a VM that reproduces the problem. Do you have some help that could try to get a VM on Azure or somewhere set up to a configuration that breaks similarly?

For exploring the pre-registration, we'd basically have to figure out how well the different COM aspects in Excel-DNA work through the regsvr32 registration. By "COM components" do you mean the ComServer support for VBA? I think that will work OK, and the ribbon has some trick I've forgotten, but can work too. So it should be possible,

But I am really interested in understanding how your environment is configured to cause this problem. I'm not getting similar reports otherwise, and I know of some other users moving to Excel 2016 this year. So something in your locked-down policy is breaking it, and maybe fixing it is as easy as changing one setting in the group policy.

[rosssaunders]

@govert Thanks v. much for the quick response.

Regarding the VM to reproduce, I'll start asking internally and try and find the team responsible for the Office deployments and configuration. It's a large financial institution so as you would imagine, this might take some time. In the meantime, I happy to investigate any suggestions or questions you have.

I do have other clients (at a different company) running Excel 2016 and ExcelDNA based add-ins without any issues so it does appear to be specific to this environment or the way Excel is deployed using Click-To-Run / App-V. Hopefully it is just a group policy that can be changed.

I have also managed to work around the issue by doing the following. (might be helpful for anyone else blocked at the moment with this issue). I did have to re-compile ExcelDNA, so if there is a better way, please let me know.

Enable VBA ComServer support

Ran regsvr32 on the XLL and removed the call in my code to "ComServer.DllRegisterServer();" in AutoOpen.

To enable the Ribbon

Removed the following lines in ExcelComAddInHelper.LoadComAddIn (lines 129-131) to stop ExcelDNA from attempting to register the Custom Ribbon in the registry.

using (new ProgIdRegistration(progId, clsId))
using (new ClsIdRegistration(clsId, progId))
using (new ComAddInRegistration(progId, friendlyName, description))

and rebuilt the ExcelDNA nuget package.

Registered the Custom Ribbon with Excel as a COM Addin via the registry

[HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ABC.Corp.CustomExcelRibbon]
"Description"="CorpExcelAddIn"
"FriendlyName"="CorpExcelAddIn"
"LoadBehavior"=dword:00000000

ensuring the LoadBehaviour is set to 0 (don't load) as we'll load it ourselves in the AutoOpen once the ExcelDNA framework has started.

Added the following code to AutoOpen

object app = ExcelDnaUtil.Application;
Type appType = app.GetType();

var appl = app as Microsoft.Office.Interop.Excel.Application;
foreach(COMAddIn ca in appl.COMAddIns)
{
   if(ca.Description.Equals("CorpExcelAddIn", StringComparison.InvariantCultureIgnoreCase))
   {
      ca.Connect = true;
   }
}

[RobertDaCosta]

Hi Govert. Long term fan. We use DNA extensively to deliver C# functionality to many trader sheets.

We are moving to a Windows 10 (64-bit) Virtual platform and have come across this error. ComAddIn [Error] RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Illegal operation attempted on a registry key that has been marked for deletion. ComAddIn [Error] RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled Initialization [Error] DnaLibrary AutoOpen Error : TargetInvocationException - Exception has been thrown by the target of an invocation.

I've also followed the bypass approach mentioned by Cedric in the article you mentioned https://groups.google.com/g/exceldna/c/TSOPygt334Y and have managed to get a working version.

It would be super helpful getting a solution to this. Let me know if I can provide any info that might help.

[rosssaunders]

@govert Thanks v. much for the quick response.

Regarding the VM to reproduce, I'll start asking internally and try and find the team responsible for the Office deployments and configuration. It's a large financial institution so as you would imagine, this might take some time. In the meantime, I happy to investigate any suggestions or questions you have.

I do have other clients (at a different company) running Excel 2016 and ExcelDNA based add-ins without any issues so it does appear to be specific to this environment or the way Excel is deployed using Click-To-Run / App-V. Hopefully it is just a group policy that can be changed.

I have also managed to work around the issue by doing the following. (might be helpful for anyone else blocked at the moment with this issue). I did have to re-compile ExcelDNA, so if there is a better way, please let me know.

Enable VBA ComServer support

Ran regsvr32 on the XLL and removed the call in my code to "ComServer.DllRegisterServer();" in AutoOpen.

To enable the Ribbon

Removed the following lines in ExcelComAddInHelper.LoadComAddIn (lines 129-131) to stop ExcelDNA from attempting to register the Custom Ribbon in the registry.

using (new ProgIdRegistration(progId, clsId))
using (new ClsIdRegistration(clsId, progId))
using (new ComAddInRegistration(progId, friendlyName, description))

and rebuilt the ExcelDNA nuget package.

Registered the Custom Ribbon with Excel as a COM Addin via the registry

[HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ABC.Corp.CustomExcelRibbon]
"Description"="CorpExcelAddIn"
"FriendlyName"="CorpExcelAddIn"
"LoadBehavior"=dword:00000000

ensuring the LoadBehaviour is set to 0 (don't load) as we'll load it ourselves in the AutoOpen once the ExcelDNA framework has started.

Added the following code to AutoOpen

object app = ExcelDnaUtil.Application;
Type appType = app.GetType();

var appl = app as Microsoft.Office.Interop.Excel.Application;
foreach(COMAddIn ca in appl.COMAddIns)
{
   if(ca.Description.Equals("CorpExcelAddIn", StringComparison.InvariantCultureIgnoreCase))
   {
      ca.Connect = true;
   }
}

Hi,

Update on this issue. It appears it is entirely due to McAfee antivirus kicking in and blocking ExcelDNA from registering the COM components.

This is from the McAfee event logs

USER1 ran C:\Windows\SysWOW64\regsvr32.exe, which tried to access HKLM\SOFTWARE\CLASSES_EXCELDNA.PERMISSIONSTEST.MACHINE, violating the rule "Modifying file extension associations", and was blocked. For information about how to respond to this event, see KB85494.

I wonder if there is a different way of testing the registry permissions that doesn't trigger McAfee?

I will attempt to find some time to test different approaches to testing the registry.

Regards,

Ross

[govert]

Thank you very much for the update.

I have in mind looking at two improvements, though can’t promise anything yet:

• Add a setting in Excel-DNA to either ignore the error when deleting the registry key, or completely skip the runtime registration (i.e. the code commented out in the code snippet below). I hope this give a way to work around the issue without making a custom Excel-DNA build, by optionally pre-registering in the registry, and then not trying to do any registration at runtime.
• A better fix might be to revisit the Windows ActivationContext API again. I had tried this in the past without being satisfied with the options. But I think it is the better approach and worth revisiting.

I suspect the McAfee block is still not the whole story, by the relatively few complaints I’ve received.

Is this still in the locked-down VM environment?

[RobertDaCosta]

@rosssaunders , do you see this issue on every run? The issue I described above is intermittent (and to be honest infrequent). We also have McAfee running on these VMs.

[rosssaunders]

@RobertDaCosta I'd say about 9 times out of 10 I see the issue. The intermittent nature of this is what caused me to stop looking at GPO / ClickToRun / AppV and look elsewhere.

Try having a look at the Application event log on your PC. There might be something interesting in there.

[govert]

We also have McAfee running on these VMs.

@RobertDaCosta Oh great - another clue.

I wonder if a default install of McAfee would break Excel-DNA. Were you not using McAfee before the migration to the VMs, or do you think the McAfee settings are different in the new environment?

[RobertDaCosta]

@govert We are migrating from Win 7 Physical desktops to Win 10 VMs. We had McAfee Endpoint Security on Win 7. It looks like there are 11 different McAfee processes running on the VM.

[rosssaunders]

@govert I'm migrating from Windows 7 with Symantec to a Win 10 with McAfee. In Win7/Symantec I never had any issues and the same code base hit problems with Win10/McAfee.

[rosssaunders]

@govert Based on the McAfee error "Modifying file extension associations", I guessed that maybe it was the key name containing a "." that was causing McAfee to jump in and block it.

I've now removed my previous changes to the ExcelDNA code and have made the following changes to the RegistrationUtil class, replacing the dots with an underscore.

const string testKeyName = "_ExcelDna.PermissionsTest.Machine"; to const string testKeyName = "_ExcelDna_PermissionsTest_Machine";

and const string testKeyName = "_ExcelDna.PermissionsTest.User"; to const string testKeyName = "_ExcelDna_PermissionsTest_User";

Along with that I put ProgId & Guid attributes onto all my ComVisible classes and made sure they did not contain any dots ".".

This has solved the problem for my code base which is great.

The names of testKeyName appear to be an implementation detail so maybe they could be changed in the next release to work around this particular McAfee issue?

p.s. I did a quick test and with this change and RTD functions implemented using Observables are still not working. The "Subscribe" method is not called so I'm guessing there is some code registering them that contains a "." in the temp name.

[govert]

Indeed, I think the built-in RTD server gets a Guid-based name like "RtdSrv.ABC123..." (ExcelRtd.cs L 132) so it would have a "." in. Maybe you can change that "." to "_" there to see if it helps to make the Observables work. If that works, there are similar "Dna." and "CtpSrv." for the ribbons and CTP controls where ProgIds that are generated. Fixing all three of these together with the probing key names, should then give a version that works as long as the user does not set explicit ProgIds with "." in.

McAfee rules

I see a bit more about the error from here https://docs.mcafee.com/bundle/endpoint-security-10.7.x-common-product-guide-windows/page/GUID-98ADE916-A3FC-4ECC-8953-C7D75AAFB71C.html

There is the file extensions rule, which presumable has the "." check in. It is on by default under the "secure"

There is also this one which is not on by default:

Installing new CLSIDs, APPIDs, and TYPELIBs | Prevents the installation or registration of new COM servers. This rule protects against adware and spyware programs that install themselves as a COM add-on Internet Explorer or Microsoft Office applications.

Do you have any way to check whether this rule is enabled? I guess not.

[rosssaunders]

I can see that rule in the event logs and indeed it is not enabled in my environment.

USER1 ran C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE, which accessed HKCU\SOFTWARE\CLASSES\TYPELIB{8328E123-8492-406D-9FDD-5F9A720ECE3C}\1.0, violating the rule "Creating new CLSIDs, APPIDs, and TYPELIBs". Access was allowed because the rule wasn't configured to block.

I'll test changing the other Guids based names as well and will let you know.

[rosssaunders]

@govert Good news, making the changes you suggested fixes the RTD using Observables and CTPs also work as expected.

[govert]

@rosssaunders @RobertDaCosta I've updated the Excel-DNA code to work around the McAfee bug now, with the dots removed from the internally generated ProgId names. I've pushed the updated version with some other fixes to NuGet as v1.2.2-preview.

I would appreciate if you could have a look, and confirm whether you can now use the standard version of Excel-DNA in this problematic McAfee environment.

[rosssaunders]

Thankyou v. much @govert. I'll be able to test later this week and will let you know.

[ricardok1]

New version worked with me (v1.2.2-preview) - Thanks!!!

[rosssaunders]

@govert I've just tested the new v1.2.2-preview and everything is working great!

Thanks v. much for all your help with this issue and getting the patch done!

[rafeeqg]

@govert - we're facing this issue in 1.2.2-preview when ExcelDNA tries to Delete the test key in our environment - Excel 365 running on Windows 10 VM on VMWare infra. From the logs we found that It is able to create the test key under HKCU however, when it tries to delete the key it hits this error and comes out. Important to note that in our case this is happening with some users only, not all

In order to fix this issue we're logging and ignoring this exception. We forked the 1.2.2-previw commit and made following changes:

1. We've put the delete test key operation RegistrationUtil.CanWriteUserHive in a try/catch bock where the error is logged only control is returned with value true since it was able Create/Open test key in the beginning.
2. Commented out RegistrationUtil.CanWriteMachineHive as that's always erroring out later in the pipeline even if we return true here

I am not sure if this is the right way to fix this issue but it is working for us. Could you please suggest and ideally if any fix is required we would like that to be done centrally rather than maintaining a custom version of ExcelDNA

[govert]

@rafeeqg Are you also running McAfee endpoint security in that environment? I'm trying to understand whether the underlying problem is the same as the one reported earlier, or just the same symptoms.

What is the exception that occurs in your environment when the key is deleted?

[rafeeqg]

Thank you @govert for your prompt reply!

Yes, we are running McAfee security in our environment

Please find the error details we get when it tries to Delete the test key. As mentioned above we log this as a Warning with custom message and move on as it doesn't impact us if it was not able to delete that key and that in the subsequent run its able to Open the test key as that's already present there

2021-03-04 12:46:18.741 +05:30 [Warning] RegistrationUtil.CanWriteUserHive - Unable to Delete test sub key - "_ExcelDna_PermissionsTest_User"
An error has occured:
"System.IO.IOException: Illegal operation attempted on a registry key that has been marked for deletion.

   at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
   at ExcelDna.ComInterop.ComRegistration.RegistrationUtil.CanWriteUserHive()"
System.IO.IOException: Illegal operation attempted on a registry key that has been marked for deletion.

   at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
   at ExcelDna.ComInterop.ComRegistration.RegistrationUtil.CanWriteUserHive()

[euri10]

greetings, we had a user facing a similar error on the ribbonit seems

I unfortunately dont have exact details but they do run McAfee and are on Office365

will try to get more details about the environment if that helps

oO and that is with the 1.2.2-preview !

ComAddIn [Error] RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Tentative d’opération non autorisée sur une clé du Registre marquée pour suppression.
ComAddIn [Error] RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled
ComAddIn [Error] The Ribbon/COM Add-In helper required by add-in SFJLemon Add-In could not be registered.
This may be due to restricted permissions on the HKCU\Software\Classes key : UnauthorizedAccessException - RegistrationUtil - Unable to write to Machine or Users hives of registry
ComAddIn [Error] RegistrationUtil.CanWriteUserHive - Unexpected exception - False : IOException - Tentative d’opération non autorisée sur une clé du Registre marquée pour suppression.
ComAddIn [Error] RegistrationUtil - Unable to write to Machine or Users hives of registry - Ribbon/COM Add-In load cancelled

[govert]

@rafeeqg @euri10 I've pushed a new update to NuGet - 'v1.2.3-preview' - that ignores errors in the registry key delete steps. Please have a look and let me know whether this version works in your environment now.

[rafeeqg]

Thank you @govert ! I'll test v1.2.3-preview and update this thread.

[euri10]

@rafeeqg @euri10 I've pushed a new update to NuGet - 'v1.2.3-preview' - that ignores errors in the registry key delete steps. Please have a look and let me know whether this version works in your environment now.

seems like it fixed the issue yes, thanks a lot

[hdwatts]

@govert A client of ours is experiencing the Registry key issue. What risks are associated with updating from 1.1.1 to the preview build where this is resolved (is there a full changelog somewhere)? Alternatively, do you have an estimation on when the next build will go stable?

[govert]

@hdwatts The complete check-in history is here on GitHub: https://github.com/Excel-DNA/ExcelDna/commits/master and a high-level summary of the changes in the upcoming version is here: https://github.com/Excel-DNA/ExcelDna/blob/master/Distribution/ChangeLog.txt

I don't know of any showstoppers in the current preview and don't plan to make any more major changes for the next release. I'll probably make a release candidate soon and wait for some feedback and increased usage before a release in the next month or two. You can estimate how widely the version has been used by checking the number of downloads from NuGet: https://www.nuget.org/packages/ExcelDna.AddIn

I think you should give it a try, and let me know if you run into any problems.