For a VSTO solution to run it must have full trust permissions.
There is only one way to trust an office solution and not display the trust prompt to the user.
Sign with an authorised certificate and add this publisher to the Trusted Publisher List
Trusting Office Solutions
VSTO does not use the Office macro security settings.
There are a number of different ways this can be done
What checks are made before a VSTO solutions will run ?
1) VSTO runtime checks if the solution requests full trust in the deployment manifest
2) VSTO runtime checks to make sure the certificate is not in the Untrusted Publisher list
3) VSTO runtime checks to see if the certificate is in the Trusted Publisher list. If so this is sufficient.
4) VSTO runtime checks to make sure the deployment manifest is not in the IE restricted zone.
1) Microsoft Office checks if the document is in the trusted locations list.
2) VSTO runtime checks if the solution requests full trust in the deployment manifest
3) VSTO runtime checks to make sure the certificate is not in the Untrusted Publisher list
4) VSTO runtime checks to see if the certificate is in the Trusted Publisher list. If so this is sufficient.
5) VSTO runtime checks to make sure the deployment manifest is not in the IE restricted zone.
When you add a folder as a trusted location, this grants full trust not to VSTO solutions but also to VBA and ActiveX code.
If you are happy to display the trust prompt you can sign with a trust certificate.
The ClickOnce Trust Prompt must be enabled
VSTO requires full trust because they interact with Office using COM Interop and because the Office object model was designed for full trust only.
Full trust is automatically granted on your development machine when you build the project. The evidence used is based on the location of the assembly.
When you deploy your solution you need to grant full trust by using a strong name or by using a digital signature to sign the assembly.
You can grant full trust to a customisation by using a certificate or by relying on the Trust Prompt.
The user will still see a trust prompt but at least it tells them that the publisher has been verified
This is also known as the ClickOnce trust prompt
This is the Microsoft Office Customization Installer dialog box
Trust Assembly - Using Installer (.msi)
These are permitted to run from the Internet because they require user interaction, ie the user needs to acknowledge and confirm that they want the installer to run.
This is very similar to it running automatically except the need to write the policy modification code as part of an Installer class.
The System.Configuration.Install.Installer class is the base class for custom installers.
By default the full path of the assembly (including the assembly name) is added to the .NET framework security policy.
It is added at the User level and is given full trust.
Any referenced assemblies in your project output folder also receive full trust when the project is built.
This automatic full trust option can be changed at a project level
Select the project node and in the properties window change the Trust Assemblies Location.
Office Trusted Locations
The Office trusted folder list is accessed from the Office icon (top right hand corner) | Excel Options | Trust Center | Trust Center Settings button | Trusted Locations tab.
We made a conscious decision not to add the folder to the Office trusted folder list (a) because administrators may not want this behaviour since it trusts a location rather than a document and (b) the document may not be in the same place as setup. For example, you may publish the customization to a UNC share but store the document in a SharePoint library.
VSTO Runtime (v4)
If you are targetting .NET Framework 4.0 and using the 2010 Tools for Office Runtime then inclusion lists are not supported. In this case you can deploy your solution to the Program Files directory which automatically has full trust anyway as it requires admin rights.
You can still use inclusion lists for Office 2007 and Office 2010 solution but you must target .NET Framework 3.5 and reference the Microsoft.VisualStudio.Tools.Office.Runtime.v10.0 assembly
VSTO Runtime (v3)
A key difference between VSTO Runtime 3.0 and VSTO Runtime 2.0 is that the security model changed
VSTO 3.0 no longer relies on CAS for security but instead introduces inclusion list security.
VSTO Runtime (v2)
Authenticode Certificates ?
If you plan on distributing to a wide public audience it might be worth considering getting an official authenticode certificate from a certifying authority
Both application manifest and deployment manifest must be signed with a certificate
This can be done using the mage.exe utility
Testing Certificates ?
These types of certificates are really designed to "get you started" and are more than suitable for intranet deployment
VSTO will automatically create a temporary certificate when a certificate does not already exist.
SS of it added to a project
A temporary certificate is created automatically every time you build the solution.
All vsto deployment manifests must be signed with a certificate
A testing certificate is also known as a temporary certificate or a self-cert certificate
When you create a VSTO project (application level or document level) a temporary certificate is created for you and automatically added to your project
This certificate has the same name of the project with "_TemporaryKey.pfx" appended to it
In a new project this certificate is setup automatically to sign the deployment manifest
This certificate is valid for one year
If your project is more than a year old then you will need to create a new certificate in order to contnue building the project.
© 2024 Better Solutions Limited. All Rights Reserved. © 2024 Better Solutions Limited TopPrevNext