Comments by Jozzle (Top 2 by date)

Jozzle 23-Dec-13 9:55am View

Thanks you for your answer. You're right. I'm not at all experienced in signing code, as i'm more focussed on WebAplications and yes, the organisation i work for is 'inflexible' to say the least...

But, i have an issue to solve, so i put your sceptic proza aside, read up on things and try to get to the next point;

Eventually my initial question is perfectly explained and partially answered by Ade Miller in this blog: http://www.ademiller.com/blogs/tech/2008/03/delay-signing-vsto-add-in-projects/

Now, i need to regenerate my .manifest & .vsto file by use of mage.exe but uses the pfx file, which makes sense, considering the public-key cryptography principles.

I've tried this locally with a temp certificate and it works like al charm. Now it's up to the security department, as i need them to use mage.exe and their .pfx to regenerate the two application files.

I've contacted them and they do not facilitate this (not yet, getting them to do so may take ages), so a subsequent question rises; is there an alternative way to get this signed .dll operational on client machines without the warning?

I have tried a Setup project (as described here, http://msdn.microsoft.com/en-us/vsto/ff937654.aspx) but that implies using the .manifest and . vsto file which brings me back to the computed hash mismatch i think.

Jozzle 20-Dec-13 10:19am View

Our security department signs .dll's only which makes the computed hash different from what the application manifest (and VSTO) expects.

I cannot simply put the .dll back into te deployment, nor do i have acces to the certificate to recomplie the deployment.

We dont have an MSI, only the .VSTO (created by a release build) or the Setup.exe,(created bij a publish action), but i think the situation is comparable to that of an MSI?