Avoiding the requirement of Trusted Location in Excel VSTO 3 document level app

Question

I have a VSTO 3 document-level application which is deployed to a shared network location.  I'd like to avoid the requirement of having the network location added to the Trusted Locations in Excel's trust center.  Is it possible to avoid this by signing the all the DLLs with our athenticode certificate?  I'm already signing the ClickOnce manifests with the certificate and the certificate's root is added to the domain's trusted publishers list.

If this is possible what is the best way to go about this?  Essentially, I want to create a deployment package that is exactly like the output produced by the "Publish Now" button on the Publish tab of Visual Studio's (2008) project properties tab.  I was thinking of a custom build script (possibly using NAnt or just a batch script).  But, I can't find documentation on the steps involved (compiling, creating the directory structure, signing the DLLs, creating the manifests, signing the manifests, etc.).  Is there an easier way?

Thanks.

Answer 1

Hello Robert.

In the architecture of customizing the 2007 Office system from this MSDN article, here I quote a statement, if the document is opened from a location other than the local computer, the Visual Studio Tools for Office runtime verifies that the location of the document is in the Trusted Locations list in the Trust Center Settings for the particular Office application. If the document location is not in a trusted location, the customization is not trusted, and the load process stops here. So here, I think when opening a document form a shared folder, it must be adding this shared file to trusted locations. 

As Mary Lee said in this thread, building the VSTO project generates a new project item which is a .pfx file. This file contains the certificated used to sign the deployment manifest. If use the VS-generated certificate, you can make it work by using the ClickOnce trust prompt.

<<Essentially, I want to create a deployment package that is exactly like the output produced by the "Publish Now" button on the Publish tab of Visual Studio's (2008) project properties tab. >>
I am not sure about this. Do you mean Windows Installer? The ways of deploying VSTO project are Publish Wizard and Windows Install.

Here are some resources which may be helpful:
Deploying Departmental Solutions via Email.
Trusting Office Solutions by Using Inclusion Lists.

Best regards,
Bessie

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Thanks for the response Bessie.

I am already signing the VSTO manifests with a specific Athenticode certificate (contained in a PFX file).  I want to use this over the VS-generated certificate because my client is trusting our root certificate from which the Athenticode certificate is based.

With regard to the "Publish Now" feature in Visual Studio 2008 - it is essentially the same as the publish wizard without the dialogs.  It is the button right next to "Publish Wizard..." on the Publish tab of the Project Properties.  It produces the same thing as the publish wizard.  It is this output that I want to mimic but with Authenticode signed DLLs.  The build and publish features of Visual Studio do not allow for Athenticode signing DLLs during the build process.  It has to be done in a custom build process (though a batch script or NAnt script or some other scripted build process).  So, I have to script a VSTO 3/ClickOnce build in order to Authenticode sign the DLLs in the project.  Whether or not that is justified is the real question...

The issue at hand is my client believes that if I Athenticode sign all the DLLs in the VSTO project it will help him avoid having to set up the Trusted Location on all the client systems.  I have been unable to determine if this is true or not.  Based on your quote from the MSDN article the Trusted Location "feature" seems to be a separate security layer that is not satisifed by signed DLLs.

Answer 3

Hello,

<<The build and publish features of Visual Studio do not allow for Athenticode signing DLLs during the build process. >>
As far as I know, we could sign the assembly on the Signing tab of project properties. When open a document from a network/shared folder, it will check if this location is trusted. For this, it will check this document's trusted locations. So here, it is little related to sign the assembly.

<<So, I have to script a VSTO 3/ClickOnce build in order to Authenticode sign the DLLs in the project.  >>
As far as I know, there are only two ways for deploying VSTO solution. I think that we only sign the manifest/assembly on Signing tab of project properties. Here is a thread which may interest you: How do you create an MSI to deploy a VSTO 3.0 Add-in.

Best regards,
Bessie

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 4

Bessie, I'm sorry but you don't seem to understand what I'm trying to do.  I need to sign the assemblies with an Authenticode certificate, not a strong-name key.  The signing tab of the Visual Studio project properties page is for strong-name signing an assembly.  Visual studio does not have an exposed feature to sign assemblies with Authenticode certificates.  That has to be done with a manual or scripted build process (possibly a post-build script).  I'm already signing the assemblies with a strong-name key, which has nothing to do with code security.  Signing them with an Authenticode certificate is a totally different animal.

The problem is, the Publish feature of Visual Studio does not run post-build scripts.  It doesn't allow for anything to be injected into the build process.  That is why I want to know EXACTLY what must be done to create a ClickOnce package for a VSTO 3 project.  I just can't believe this isn't a more common request.  I also can't believe that seemingly nobody else has wanted to satisfy the Trusted Location requirement by some other means than adding a directory to the Trusted Location list.  I have yet to confirm that if assemblies are signed with a trusted Authenticode certificate that will satisfy the Office trust requirement.  If it doesn't, it should.

An MSI isn't going to work.  This needs to be a ClickOnce deployment.  We want automatic updates and offline usage of the application (automatic caching).

<rant>
Consequently, I've done MSIs for VSTO projects deployed to a network location and it is a major pain in the rear with all the stuff involved (like CAS policies and embedded manifests and manifest pointers, etc.).  Microsoft really needs to clean VSTO up with regard to deployment and security.  It's too much of a hassle - we might as well go back to VBA due to the tedious difficulties that come with VSTO.
<rant />

Answer 5

Hello again Robert,

In security of office solutions, when a document-level customization is loaded, the VSTO 3.0 Runtime always checks whether the document is in the trusted locations list.  For document-level solution, the document of a document-level solution must be in a trusted location. If the document is on a remote network file share or has a .doc or .docm file name extension, the document's location must be added to the trusted locations list. You want to satisfy the Trust Location requirement by signing the assemblies. As far as I know, it is little related to this, and only way for this is to add a location to the trusted locations list. You could refer to this MSDN article: Security in Office Solutions.

Sorry for mistaking this, yes, in the signing tab of project properties, there are two options: sign the clickonce manifest and sign the assembly by using a strong name. However, this is related to code security. Code security and Office security are different mechanisms.

As you mentioned above, it seems that you have download this document using this customization on local computer. If yes, the local computer is considered a trusted location. So there is no need to add shared location to trusted locations list. If we opening this document online, a dialog appears indicting the location is not in the trusted locations list. For this, it has listed in this MSDN article. In general, this document file is downloaded on local files by users.

Best regards,
Bessie

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.