Debugging .NET Framework working only “sometimes”

I am these days (well, nights) debugging an extremely difficult issue with the ImageList control and I had that idea that debugging the .NET Framework (source step) would help a lot. That feature was introduced in VS 2008 and my feeling these years when I tested it from time to time was that sometimes it worked, sometimes it didn’t. Yesterday that I needed it badly I searched the web and I discovered that I was not alone. There are tons of issues and workarounds about it. I tried all them to no avail.

Finally someone from Microsoft posted here (only a few weeks ago after all these years!) that the root cause is out-of-date PDBs, and that it is going to happen each time that Microsoft releases a new build of an assembly, which is not only in service packs but also any security patch. Since there is cadence between the release of the assembly and the release of the PDB (that has been up to 1 year in the past!), this feature is basically broken, bad designed.

The alternative, suggested strongly by that guy, is to use .NET Reflector, a paid tool which for developers of Visual Studio extensions is even more useful to debug Visual Studio assemblies (not just .NET Framework assemblies) as I explained in this guest post on their blog.

Msaddndr.dll file officially not installed by Microsoft Office 2013

As I posted back in November, the setup of an add-in for the VBA editor of Office 2013 written with VB6 could fail with the following error:

“Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”

I mentioned that the cause was that the file Msaddndr.dll is no longer installed by Office 2013 and today I have found that Microsoft wrote an official Knowledge Base (KB) article stating it a month later:

A custom add-in that uses interfaces in the Msaddndr.dll file does not work in Office 2013
http://support.microsoft.com/kb/2792179

The workaround is, of course, that your setup installs that file. BTW, I got yesterday a bug report from a user of my MZ-Tools 3.0 for VBA with that same error but using a MZTools3VBASetup.exe that already (supposedly) installed the file. It happened that the system already had that file installed, but an old version, and the setup only installed it if not present, so it was not replaced by the newest version. So, when applying this workaround, ensure that your setup installs the file if not present, or if it is an older version, because it seems that there are at least two versions of Msaddndr.dll out there.