In the last couple of days two users of my add-in MZ-Tools 3.0 for VBA have reported me that the (latest) setup failed with error “Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”.

Again?

After discovering some months ago that the problem happened because Office 2013 no longer ships the MSADDNDR.DLL file, officially confirmed by Microsoft, I modified the setup to install that file if missing. Then I had to modify the setup again because apparently an older version of that file didn’t work either, so the setup installs it now “if missing” or “if present file older”.

And then, these two bug reports with the same problem? One of the users provided me the version installed on his system: 12.0.20617.1, and a copy, so I could reproduce the problem. Where does that version “12.0.20617.1” come from, if older versions were “6.x.y.z”?. At first I thought about Office 2010 (internally version 12.0), but once I verified with Orca.exe that it ships version 6.x, I searched the term 12.0.20617.1 on the web, and you know what? It is installed by VS 2013 Preview (internally version 12.0)! (I have verified and reproduced the problem). And why does it break existing setups that ship version 6.x? Because it is not backwards compatible! I explain the details in this bug report that I have opened at Microsoft Connect:

MSADDNDR.DLL 12.0.20617.1 installed by VS 2013 Preview breaks setups of VBA add-ins
http://connect.microsoft.com/VisualStudio/feedback/details/793386/msaddndr-dll-12-0-20617-1-installed-by-vs-2013-preview-breaks-setups-of-vba-add-ins

The workaround is easy: force the setup to install its version, not matter which version is installed, but I want to know from Microsoft if I will break VS 2013 doing that.