Hi Dean,

Are you opening the file via VBA code in the add-in (This should take
advantage of msoAutomationSecurityLow)? Otherwise, the result you describe
in your 1st paragraph seems inconsistent with all else I've learned.

Can you confirm that the signature is still valid in the modified file with
the sheet deleted (Maybe remove the add-in, then open the modified file and
expect the error when the add-in is not found by the functioning VBA code)?

Best Regards,
Walt

"Dean J." wrote:

I added a reference to the Add-In and created a wrapper procedure that called
the Add-In to delete a sheet. I tried the workbook on the client PC (without
the private key certificate) and it worked fine...meaning it deleted the
sheet and saved the workbook without invalidating the certificate (public
key).

Actually, now that I think about it, the point of a macro virus is to be
attached to the workbook and do it's harm when the workbook opens. So it
would make sense that an add-in (something you usually have to install
yourself) wouldn't fall into the macro virus category, and thus Excel would
allow it to change the VBA project (what happens when adding/deleting a
sheet) without invalidating the certificate.

My personal opinion is that if you have imported the publisher's public
certificate and selected the "Trust all macros from this publisher" checkbox
when opening the workbook, then macros that change the VBA project should be
OK and not require the re-signing of the project. But I guess when the
programmer signs the VBA project, it uses the current object list (number of
sheets, etc.) in the hash, and once that changes it must be re-signed, which
can't be done on the client because they don't have the private key
certificate. Essentially a catch-22.

Dean

"Bob Phillips" wrote:



"Dean J." wrote in message
...
I'm thinking that the reason the add-works is that it's
*totally* separate from the workbook, whereas my DLL is still linked in by
a
project reference.

You could test that by referencing the add-in in the project.