Programmatically rebuild .exd-files when loading VBA

Question

After updating Microsoft Office 2007 to Office 2010 some custom VBA scripts embedded in our software failed to compile with the following error message:

Object library invalid or contains references to object definitions that could not be found.

As far as I know, this error is a result of a security update from Microsoft (Microsoft Security Advisory 960715). When adding ActiveX-controls to VBA scripts, information about the controls are stored in cache files on the local hard drive (.exd-files). The security update modified some of these controls, but the .exd-files were not automatically updated. When the VBA scripts try to load the old versions of the controls stored in the cached files, the error occurs. These cache-files must be removed from the hard drive in order for the controls to load successfully (which will create new, updated .exd-files automatically).

What I would like to do is to programmatically (using Visual C++) remove the outdated .exd-files when our software loads. When opening a VBA project using CApcProject::ApcProject.Open I set the following flag:axProjectThrowAwayCompiledState.

TestHR(ApcProject.Open(pHost, (MSAPC::AxProjectFlag) (MSAPC::axProjectNormal | MSAPC::axProjectThrowAwayCompiledState)));

According to the documentation, this flag should cause the VBA project to be recompiled and the temporary files to be deleted and rebuilt. I've also tried to update the checksum of the host application type library which should have the same effect. However none of these fixes seem to do the job and I'm running out of ideas.

Disquieting

I would sugest that you first try to delete the .exd files manually to verify that it solves your problem (before trying to do it programmatically). In my case it did NOT solve the problem. #4495502 – Earthstar

It could be the KillBit issue you refer to , or it could be other things. Did you upgrade from x86 Office 2007 to x64 Office 2010? Have you checked your VBA references for missing items? Do you get the "Compile error in hidden module" error? Have you reviewed blogs.msdn.com/b/vsod/archive/2009/06/05/…? Have you unchecked "Ignore Other Applications That Use Dynamic Data Exchange (DDE)" in Excel options? Agreed with @CaBieberach, you may need to confirm that this is actually the issue first by manually deleting .exd. – Rumery

We have verified that deleting the exd-files solves the problem (by doing it manually on several test machines). The problem arises when upgrading to the x86 version of Office (we do not support Office 2010 x64 in combination with our software). For now, when a customer experiences this problem we let them run a script that deletes all exd-files. – Disquieting

Answer 1

I encountered this problem some times ago, and the recommended (and working) solution indeed was to delete all .exd files on the system drive. Obviously they are rebuilt whenever needed, so there is no need to programmatically trigger the rebuild process.

Himation

Problem is I actually need to do it programmatically. But it's been almost a year without finding a way to do it so I'll accept this answer and move on with my life ;) – Disquieting