Add-in compiles without errors but refuses to register/unregister

OliverM

Guest

While testing the task pane behavior mentioned in my former post, I added task panes for testing purposes. Having finished testing, I deleted the additional panes in order to continue with normal developing tasks.

A few minutes later, starting Excel from VS for a test run, I noticed my add-in ribbon tab is missing.
I double checked via the COM add-in dialog - my add-in was still loaded, only the ribbon was missing.
Unregistering then registering it again will do the trick, I thought, but I ended up with this:

Detailed technical information follows:
---
(Inner Exception)
Date and Time: 02/01/2018 14:45:03
Machine Name: BADATTITUDE
IP Address: 1.2.3.4.5.6
Current User: BADATTITUDE\Tom

Application Domain: DefaultDomain
Assembly Codebase: file:///C:/Program Files (x86)/Add-in Express/Add-in Express for .NET/Bin/Packages/VS2005/AddinExpress.Wizard.dll
Assembly Full Name: AddinExpress.Wizard, Version=8.7.4430.0, Culture=neutral, PublicKeyToken=4416dd98f0861965
Assembly Version: 8.7.4430.0

Exception Source: mscorlib
Exception Type: System.Runtime.InteropServices.COMException
Exception Message: Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))

---- Stack Trace ----
at System.RuntimeType.GetTypeFromProgIDImpl(String progID, String server, Boolean throwOnError)
at AddinExpress.Projects.Common.Registrator.CheckCustomTaskPanes(Object adxModule, Boolean register)
at AddinExpress.Projects.Common.Registrator.RegisterAddinModule(Type t, BuildMode buildMode)
at AddinExpress.Projects.Common.Registrator.RegisterAssembly(Int32 rtmType, Int32 bMode, String projectFolder, String configurationName, String primaryOutput, String projectKind, String projectFullName, Boolean registerOutputState, Boolean prismBugMode, Boolean expressEdition)

(Outer Exception)
Date and Time: 02/01/2018 14:45:03
Machine Name: BADATTITUDE
IP Address: fe80::55cf:f587:9ca2:28a3%4
Current User: BADATTITUDE\Tom

Application Domain: DefaultDomain
Assembly Codebase: file:///C:/Program Files (x86)/Add-in Express/Add-in Express for .NET/Bin/Packages/VS2005/AddinExpress.Wizard.dll
Assembly Full Name: AddinExpress.Wizard, Version=8.7.4430.0, Culture=neutral, PublicKeyToken=4416dd98f0861965
Assembly Version: 8.7.4430.0

Exception Source: AddinExpress.Wizard
Exception Type: System.Exception
Exception Message: The 'RegisterAssembly' function failed.
Exception Target Site: dteBuildEvents_OnBuildProjConfigDone

---- Stack Trace ----
AddinExpress.Projects.Common.Registrator.dteBuildEvents_OnBuildProjConfigDone(projectUniqueName As String, ProjectConfig As String, Platform As String, SolutionConfig As String, Success As Boolean)
AddinExpress.Wizard.dll: N 1552 (0x610) IL

Over the last 3 years I have seen a small number of opportunities where the un-/registration process failed, but restarting VS or sometimes restarting Windows always solved the issue.
I understand from the error message that the ADX wizard is complaining about a certain PROGID and/or class name while checking my task panes. But why VS is not complaining when building the project? I deleted bin and obj folders, nothing helped. Any help greatly appreciated!

Andrei Smolin

Add-in Express team

Posts: 18825
Joined: 2006-05-11

Hello Oliver,

Start with deleting items from the TaskPanes collection of the add-in module. Also check that InitializeComponent doesn't create custom task panes.

Andrei Smolin
Add-in Express Team Leader

OliverM

Guest

Hi Andrei,

No error popped up at program start up and the application worked like normal up to the point where I tried to un/register the add-in. Then the above mentioned scary error was thrown.
After lots of back and forth I found out, even if registration seemed to fail my add-in un/registered as usual and worked without restriction, which increased confusion on my side.
As it turned out an abandoned entry for a standard Excel task pane in the AddinModule.TaskPanes collection caused the registration error. Opposite to an ADX pane a standard pane seems not to be created together with the workbook window. That would explain why a registration error is thrown but a registered add-in starts and works like normal as long as no calls are made to the "missing" pane. I believe when working with ADX panes, you can never get into that situation because ADX panes are created when a book is opened/created, and if an entry in the task pane manager points to a non existing task pane class, the result in an immediate run-time error.

It would be great, if you guys could find a way to check standard Excel task panes not only at registration but at compile time as well.

Andrei Smolin

Add-in Express team

Posts: 18825
Joined: 2006-05-11

Oliver,

Is it possible that you've changed the add-in's namespace recently but the item in the TaskPanes collection still mentions the old namespace?

OliverM writes:
even if registration seemed to fail my add-in un/registered as usual and worked without restriction, which increased confusion on my side.

If the registration process fails, no entries are written to the registry and your add-in won't load. Since it loads in your case, this means you haven't unregistered it.

OliverM writes:
Opposite to an ADX pane a standard pane seems not to be created together with the workbook window.

No panes are created beforehand. Whether you talk about a custom task pane or Add-in Express pane, the pane is created when the current context matches that associated with the pane. For Add-in Express panes, Add-in Express tracks the context. As to custom task panes, this is Office who sends your add-in a "create a pane" signal; Add-in Express intercepts it and if the ProgId specified in the TaskPanes collection isn't found in the add-in, Add-in Express raises a run-time exception.

OliverM writes:
It would be great, if you guys could find a way to check standard Excel task panes not only at registration but at compile time as well.

I believe there's no compensation for the difficulties and compile-time delays associated with implementing such a feature.

Andrei Smolin
Add-in Express Team Leader

OliverM

Guest

Is it possible that you've changed the add-in's namespace recently but the item in the TaskPanes collection still mentions the old namespace?

No, I did not.

If the registration process fails, no entries are written to the registry and your add-in won't load

Andrei, sorry for disagreeing but I see a different behavior. Consider a scenario with 2 panes. 1 ADX, 1 standard. Both panes are correctly added to the task pane manager/AddinModule.TaskPanes collection.
Register the add-in and start => of course all fine.
Unregister the add-in and start => of course all fine.
Now change the ControlProgID in the AddinModule.TaskPanes collection to a not existing class name.
Register the add-in => above documented error is thrown BUT nevertheless the add-in is registered, ribbon is there, ADX pane is created.
Unregister the add-in, same error as above BUT the add-in is unregistered and the next time you start no ribbon, no ADX pane shows up.

Add-in Express intercepts it and if the ProgId specified in the TaskPanes collection isn't found in the add-in, Add-in Express raises a run-time exception.

Unfortunately not ;-)

Andrei Smolin

Add-in Express team

Posts: 18825
Joined: 2006-05-11

Hello Oliver,

No problem with disagreeing. Hope you understand this. The last thing I would want is to misinform you or any other developer.

I'll check your scenario and report my findings here.

Andrei Smolin
Add-in Express Team Leader

OliverM

Guest

Hi Andrei,

I am a big fanboy of the way you provide support to your customers and I would never assume that you want to misinform them!

Do you want me to send the test project over, to make sure we are working on the exact same scenario?

Andrei Smolin

Add-in Express team

Posts: 18825
Joined: 2006-05-11

Thank you Oliver.

It appears I was about to misinform you after all. Of course, I didn't want to. My apologies anyway. I reproduced the issue and it was quite a surprise. After talking with our guys, I've got a different picture.

An add-in assembly is a set of COM-visible classes: the add-in module and all other Add-in Express modules (such as XLL module, additional module, etc.) or custom COM classes (such as a class allowing VBA macro to get events from your add-in). When you register/unregister the add-in, you register/unregister each of the COM-visible classes.

When you register the add-in from the IDE, these classes are registered by Visual Studio, not by Add-in Express. This also explains why you get this exception if you unregister the add-in in the scenario you describe. At the install time, this work is done by the adxregistrator utility.

In fact, Visual Studio and adxregistrator don't know that they register a COM add-in. The registration code is generic in both cases: they create registry entries for every COM-visible class and call the methods having the ComRegisterFunctionAttribute on them; Add-in Express sets this attribute on the ADXRegister and ADXUnregister methods (see the add-in module) - the methods perform the registration in a way specific to COM add-ins (or RTD servers, or Smart tags, etc.)

Add-in Express registers custom task panes in the way required by Office (this also checks the availability of UserControls you've specified) after VS registers all other COM classes. To do this, it loads the assembly to an AppDomain, scans the TaskPanes collection, for each ADXTaskPane it tries to create an object using the ProgId information: in the test scenario above, this attempt causes an exception that you see during the registration process.

If this exception occurs at the install time i.e. when adxregistrator registers the add-in, the exception causes adxregistrator to return a non-zero value and, provided that you don't ignore the return value (you don't ignore it by default), the exception results in your installation failing. BTW, when adxregistrator is run to unregister the add-in, it ignores as many exceptions as possible.

If the exception occurs when registering the add-in from the IDE, all other COM classes in your assembly will be registered correctly. If you load the add-in, it simply won't show the pane: it isn't registered and Office doesn't request the add-in to show it. The only way for us to prevent the add-in from getting registered in this scenario would be to unregister it. We don't do this because we would get many other difficulties. We plan to use adxregistrator to register/unregister the add-in when you do this from the IDE. This would also prevent the add-in from being registered in this scenario.

Still, switching to using adxregistrator.exe to register the add-in from the IDE is a very significant change. Although it would allow us to solve some problems (such as the need for administrative permissions to develop a per-user add-in), it will raise some difficulties such as a growing volume of support work :). But putting this aside, the change is very serious and I can't tell when it will be implemented.

Note that so far I've talked about registering (unregistering) the add-in. For the sake of completeness, I need to mention run-time exceptions.

If you register the add-in from the IDE, modify the ProgId of a custom task pane after this, and compile the project, you'll get Unable to create specified ActiveX control; see also https://www.add-in-express.com/forum/read.php?FID=5&TID=14616&MID=74966#message74966. Another way to get this exception is to generate an exception in the constructor of the UserControl that represents the custom task pane.

The above applies to registering custom task panes. Add-in Express panes are not COM objects; they are not registered at all. Currently, there's no code that checks whether the class name you specify for an Add-in Express task pane is correct or not. We will consider adding such code.

I've re-read the thread above and noticed this symptom:

OliverM writes:
my add-in was still loaded, only the ribbon was missing

In the Visual Studio IDE, open Tools | Options, click Windows Forms Designer and set Optimized Code Generation = False. If set to true, it may cause the issue described at https://www.add-in-express.com/forum/read.php?FID=5&TID=14238.

Phew...

Andrei Smolin
Add-in Express Team Leader

OliverM

Guest

Hi Andrei,

Thank you very much for the detailed explanation. I now much better understand what is going on under the hood.

In the Visual Studio IDE, open Tools | Options, click Windows Forms Designer and set Optimized Code Generation = False. If set to true

Not sure if that was the reason, but changed the setting according to you recommendation.