Rubberduck: RD unhandled exception on start up.

[jhiston]

On one particular Access DB file I get a Fatal RD error when loading the VBIDE and RD has just loaded its splash screen.

Error is: ";Startup sequence threw an unexpected exception.;System.ArgumentException: An item with the same key has already been added." (Full log below)

Office 365, Windows 10. RD loads with all my other Access files. VBIDE still loads and Access compiles the file with no concerns (option explicit is present on all modules)). File being opened has one reference to a separate Access DB file (used as a type library).

Other details that may/may not be relevant:

• The project names are different for the two Access files (seeing the error seems to be associated with registering components).
• All code modules have distinct names in the two files
• I have long module names (longest is "I_CC_frm_ContAsLB_1Core_Marker_OwnsContinuousActingAsListbox") and I notice that RD does not handle renaming class/interface code modules that have names that long (seems to have a much shorter length limit than the VBIDE when trying to use the rename functionality on a module name). BUT, I also have similar lengthy names in files that are opening with no problems.

2018-06-01 09:40:48.5593;FATAL-;Rubberduck._Extension;Startup sequence threw an unexpected exception.;System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary```2.Insert(TKey key, TValue value, Boolean add) at Rubberduck.VBEditor.Events.VBEEvents.RegisterComponents(IVBProject project) in C:\projects\rubberduck\Rubberduck.VBEEditor\Events\VBEEvents.cs:line 81 at Rubberduck.VBEditor.Events.VBEEvents..ctor(IVBE vbe) in C:\projects\rubberduck\Rubberduck.VBEEditor\Events\VBEEvents.cs:line 63 at Rubberduck.VBEditor.Events.VBEEvents.Initialize(IVBE vbe) in C:\projects\rubberduck\Rubberduck.VBEEditor\Events\VBEEvents.cs:line 22 at Rubberduck.Root.RubberduckIoCInstaller.RegisterConstantVbeAndAddIn(IWindsorContainer container) in C:\projects\rubberduck\Rubberduck.Main\Root\RubberduckIoCInstaller.cs:line 814 at Rubberduck.Root.RubberduckIoCInstaller.Install(IWindsorContainer container, IConfigurationStore store) in C:\projects\rubberduck\Rubberduck.Main\Root\RubberduckIoCInstaller.cs:line 86 at Castle.Windsor.WindsorContainer.Install(IWindsorInstaller[] installers, DefaultComponentInstaller scope) at Castle.Windsor.WindsorContainer.Install(IWindsorInstaller[] installers) at Rubberduck._Extension.Startup() in C:\projects\rubberduck\Rubberduck.Main\Extension.cs:line 221 2018-06-01 09:40:48.5926;FATAL-;Rubberduck._Extension;System.Exception: Rubberduck's startup sequence threw an unexpected exception. Please check the Rubberduck logs for more information and report an issue if necessary at Rubberduck._Extension.Startup() in C:\projects\rubberduck\Rubberduck.Main\Extension.cs:line 234 at Rubberduck._Extension.InitializeAddIn() in C:\projects\rubberduck\Rubberduck.Main\Extension.cs:line 189;System.Exception: Rubberduck's startup sequence threw an unexpected exception. Please check the Rubberduck logs for more information and report an issue if necessary at Rubberduck._Extension.Startup() in C:\projects\rubberduck\Rubberduck.Main\Extension.cs:line 234 at Rubberduck._Extension.InitializeAddIn() in C:\projects\rubberduck\Rubberduck.Main\Extension.cs:line 189

[retailcoder]

Thanks for reporting - seems the top part of the log is missing, where the version information is. What build are you running? You can also copy this information from the 'about' dialog. Thanks!

[bclothier]

What I don't see is the version of RD. That was an error that was fixed -- If this is a green release, then you might not have that fix. See #3954 & #3989

You can obtain the latest dev release or if you prefer, the release associated w/ #3989 here:

https://github.com/rubberduck-vba/Rubberduck/releases/tag/Rubberduck-v2.2.0.3201

[jhiston]

Version from the about dialog is:

Version 2.2.6672.28001
OS: Microsoft Windows NT 10.0.16299.0, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.9330.2087
Host Executable: MSACCESS.EXE

(code pasted above in original post was full content of the RubberduckLog.txt file)

[jhiston]

Not sure I fully have understood in general sense the releases 'pattern' in GitHub, but from what I understood from links @bclothier provided,

• there was a known issue (the #3954 reference)
• it was still present in the last 'stable' release ("Green release", e.g. Rubberduck v2.2.0.3086 - as linked to on Rubberduck News)
• a Dev release since then (v2.2.0.3201) has the fix for the issue
• that Dev release can be considered a 'recommended for daily amateur coder' use (e.g. not necessarily at level of a 'stable' release, but perfectly fine for daily use)

Is there anything I might have done that would have created the duplicate project ids?

Thanks - I will try the later release and report back if find problem continues to exist.

[retailcoder]

The only reason 'pre-release' builds aren't deemed "stable" is because they're generated automatically every time a pull request is merged: sometimes large architectural changes are split into multiple PR's, making the builds in-between somewhat likely to have issues that wouldn't show up in a "green" release, for example missing resource keys and/or translations.

Also we don't want to annoy everyone with "hey a new version is available" every single time a pull request is merged =)

[bclothier]

Yes, you got it.

No, it's not a problem on your part. We are the one who generate IDs and try to make it unique but the bug was that we don't correctly guard for duplicates which requires generating a new unique ID just in the time.

[jhiston]

Release Rubberduck v2.2.0.3291-pre (picked somewhat at random but as something near latest but not the absolute latest) has loaded the file with no problems.

Thanks to all for your quick responses and hard work on the RD product.

[jhiston]

Actually - sorry while I have your 'attention', could anyone comment on the restriction on the length of a code module (last bullet point in original post).

With the 3291 release (and earlier), if I right click the module name on my "I_CC_frm_ContAsLB_1Core_Marker_OwnsContinuousActingAsListbox" class, RD won't accept any 're-name' longer than "I_CC_frm_ContAsLB_1Core_Marker_", but VBIDE seems happy with the longer names.

I haven't searched recently for a corresponding issue being open, would you like me to open one, or is there a known limitation I haven't seen (I remember finding something in an earlier search about character limits but it is escaping me know and not sure what the desired protocol is for an issue like this).

Thanks

[retailcoder]

IIRC we constrained lengths because of problems with Application.Run (i.e. unit testing) when the fully-qualified member name (including file path) exceeds 255 characters - might be something else though, but if that is the reason then we can probably lift it now that unit testing no longer works off Application.Run... worth opening a new issue for that =)