none
Error while opening VSTO document-level add-in RRS feed

  • Question

  • Hello experts,

    We have developed a document-level add-in application for MS Excel. To start the application, we deliver the template file ExcelWorkbook.xltm which contains VBA code. This VBA code together with the VSTO file and manifest are signed by our company certificate. We (app developers) do not have this certificate available, the signing happens in an automated way on build server. The bugfixes are then delivered with each patch every few months.

    However, in some cases the end users cannot wait several months to get the bugfix with next patch with officially signed files. Therefore, as temporary solution, we provide to the user the latest DLL's and VSTO signed by test certificate which we create directly on DEV machine. Until recently this worked well as follows: user uninstalled the old customization, overwrote the old DLL's, VSTO, manifest and template with the new ones (signed by test certificate only); upon starting the new template, only a warning was raised that the code is signed with some temporary certification was displayed, but the user was able to continue the installation of the new customization.

    However, recently this has changed and when user starts the new template, the famous error is displayed:

    "This document contains custom code that cannot be loaded because the location is not in your trusted locations list:..."

    We don't want to force the user to add the installation folder into the list of trusted locations due to security reasons. Why user is not able to install the customization which is signed with temporary certificate anymore? This worked before. Was there recently any MS Windows or MS Office update that has toughen the security in this respect?

    Is it possible to achieve it somehow without adding the folder into trusted locations?

    Thank you and best regards,
    Tomas 

    Tuesday, August 5, 2014 8:17 AM

All replies

  • Hi Tomas,

    >>

    We don't want to force the user to add the installation folder into the list of trusted locations due to security reasons

    Is it possible to achieve it somehow without adding the folder into trusted locations?

    <<

    The first security check applies only to document-level solutions. The document of a document-level solution must be in a trusted location. When a document-level customization is loaded, the Visual Studio Tools for Office runtime always checks whether the document is in the trusted locations list. So I’m afraid the customization from a un-trust location would not be loaded (it is also due the security).

    >> Why user is not able to install the customization which is signed with temporary certificate anymore?

    Visual Studio creates a temporary certificate if a signing certificate does not already exist. You should use this temporary certificate only during development, and purchase an official certificate for deployment.

    The temporary certificate is generated after an Office project is first built. The next time you press F5, the project is rebuilt because the project is marked as changed when the certificate is added.

    There can be many temporary certificates after a while, so you should clear the temporary certificates occasionally.

    The temporary certificate should be able to work in your test environment. In your case, since the document did not pass the first security, so I don’t your issue is caused by the temporary certificate.

    For more detail information, please refer to Securing Office Solutions.

    Please correct me if I have any misunderstanding, hope it will help.

    Regards,

    Jeffrey


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, August 6, 2014 5:00 AM
    Moderator
  • Hi Jeffrey,

    thank you for your time to look into this.

    You stated following:

    The first security check applies only to document-level solutions. The document of a document-level solution must be in a trusted location. When a document-level customization is loaded, the Visual Studio Tools for Office runtime always checks whether the document is in the trusted locations list. So I’m afraid the customization from a un-trust location would not be loaded (it is also due the security).

    I am sorry, but it does not work in this way, at least not in our case. For us it works as follows:

    • When the VSTO and manifest are signed by the official certificate of our company, then the customization is loaded automatically even from folder which is NOT in trusted locations list without any prompt to the user.
    • When it is signed only by the test certificate (which we created directly in the VS2010, project properties, tab Signing) then the customization was loaded as well, only there was a pop-up that the certificate is not trusted, but user could still press the "Install" button and install this customization. It worked this way for over a year now since we do the support for our product this way. About a month ago, this stopped working.

    Btw, exactly this behavior which I expect is also described on the page which you send me:

    [For some reason, I am not able to add link here. But it is page called "Granting Trust to Office Solutions" which available as sublink on the link which you have posted.]

    A temporary certificate is created for you and granted trust at build time so the solution will run while you debug it. If you publish a solution that is signed with a temporary certificate, the end user will be prompted to make a trust decision.

    If you sign the solution with a known and trusted certificate, the solution will automatically be installed without prompting the end user to make a trust decision.

    It is either a bug or I am missing something...

    Best regards,
    Tomas




    Wednesday, August 6, 2014 7:20 AM
  • Hi Tomas,

    >> I am sorry, but it does not work in this way, at least not in our case. For us it works as follows…

    Thanks for sharing the detail information, I will also test it in my lab environments and I will let your know if I have any updates on it.

    [Update]

    I’m trying to involve some senior engineers to look into this issue. It will take some time, thanks for your patience.

    Regards,

    Jeffrey


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, August 11, 2014 8:26 AM
    Moderator
  • Hi Tomas,

    I presume that you have the Installation folder at a network location. If yes the following applies:

    A document-level project has the same security requirements as application-level projects: signing the manifests with a certificate or clicking the trust prompt. In addition, the document or workbook must be located in a directory that is designated as a trusted location.

    This is documented here

    http://msdn.microsoft.com/en-us/library/bb157863.aspx#VisualStudioToolsForOfficeRuntime

    I can confirm that there are no changes on security part recently.

    Local folders are considered to be more secure and are implicitly trusted. If you wish not to have end users to add install folder to their network location , you can probably consider moving installation folder to local folders.

                                                                                   


    Sangeeth,MSFT

    Tuesday, August 12, 2014 3:45 PM
  • Hi Sangeeth,

    the application is installed into the "Program Files" folder. To install and deliver the application, we do not use the "Publish" feature of the Visual Studio, we use our companys installer instead. It simply copies all the files into this folder (for 64bit win): "c:\Program Files (x86)\XYZ\AXL\".

    Best regards, Tomas

    Wednesday, August 13, 2014 11:00 AM
  • Hi Sangeeth,

    I have prepared document with details about this issue including screnshots. If you are interested, I can share it with you. Can we use some private channel for that? I would not like to disclose it here publicly.

    Bets regards,
    Tomas  

    Wednesday, August 13, 2014 2:37 PM
  • Hi Tomas,

    It seems we might need to do deeper analysis of this scenario. Because of its complexity your question falls into the paid support category which requires a more in-depth level of support.  If the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Thanks

    Sangeeth


    Sangeeth,MSFT

    Thursday, August 14, 2014 2:06 PM