OK, that’s the same as on my production system. I checked, there’s no .NET framework 4.0 on that machine either, just 4.5 (which evidently provides backward compatibility).
Coincidentally, my ‘production’ Excel crashed at work just yesterday, and afterwards, the Toolbox NG would not longer be loaded. Neither did it appear under Add-ins -> COM add-ins.
Depending how adventurous you are, you can try one of the following:
Change the name of the registry key for the add-in as shown below. Just append some arbitrary text to the key name (‘123’ in this case). That’s what I did to get my NG back. I had to manually check the checkbox in Add-ins -> COM add-ins though.
This is the situation that I have with our in-house Word add-in on the zero clients that reset the user profile every day (kind of annoying). The add-in is lost after reset. Just re-installing it does not help. Apparently Office applications have a memory of add-ins they had loaded at some point, but I don’t know (and the internet doesn’t either) where that memory is. It’s not ‘disabled add-ins’ (the solution most commonly suggested on the internet).
Alternatively, you could try to obtain some debugging information first. This requires setting an environment variable “VSTO_SUPPRESSDISPLAYALERTS” as described in http://www.xltoolbox.net/blog/2015/01/troubleshooting-vsto-add-ins-for-office.html.
BTW, unlike VBA/.xlam add-ins, the add-in information for VSTO add-ins in the registry is Office version agnostic. Look at the screenshot, the registry key does not contain the Excel version. So one VSTO add-in should be enabled for all Office versions that support VSTO add-ins. (However, MS does not recomment parallell installations of Office versions.)