none
VSTO Add-In error when opening a Word 2010 file via Sharepoint Explorer view

    Question

  • We have a VSTO Word add-in deployed as a click-once installation, and I'm attempting to diagnose an error which occurs when a user opens a Word document from SharePoint 2010 via the explorer view. Very similar to this recently diagnosed issue I found:

    http://social.msdn.microsoft.com/Forums/pl/vsto/thread/d8de258b-528f-4f39-ab5f-355e837f8aa6

    with the exception that we are not using SSL. We are however using a port designation (port 81) on our SharePoint URL, and when checking the UNC for a file via the SharePoint explorer view, it shows as such:

    \\<sharepointserver>@81\DavWWWRoot\groups\it\projects

    I notice we have an ampersand in the UNC just as the SSL url in the above link.

    Are these two problems related? 


    Monday, June 04, 2012 8:19 PM

Answers

  • Hi Forrest, no problem - it's a strange combination of effects. I think our solution going forward will be to get rid of app.config use in our add-in and just re-deploy it. If you do come up with any more info on this please let us know. Many thanks,


    Brad

    Monday, June 18, 2012 3:09 PM

All replies

  • can you confirm that vsto add-in loads fine when you access document through standard web browser interface (http)?
    Tuesday, June 05, 2012 8:07 AM
  • Hi,

    Regardless how the @ sign is introduced, it is preventing VSTO applications from loading.  I'll suggest you using default port for Sharepoint site, this way the path to the customized document become normal UNC path like \\servername\Contoso\SharedDocument . Add the location to trusted location, you'll be able to run the customization.

    Note that I didn't touch WebDav.


    Forrest Guo | MSDN Community Support | Feedback to manager


    Friday, June 08, 2012 4:49 AM
    Moderator
  • Thank you for your reply Forrest, I did some further digging and I narrowed the culprit to two settings:

    1) We're using SharePoint Explorer view (WEBDAV) to view word docs, and the SharePoint site has a port number :81. We know that the WEBDAV request (I assume) changes the : to an @, and that seems to be part of the issue.

    2) I got to thinking about why other addins we have didn't fail. I ended up tracing to another contributing factor - We build our addins with VS 2010 SP1, and they load with VSTO SP1. There's a change to the path form in the add-in registry key "Manifest" for click-once add-in installs. We had to add "file:///" to the local manifest path in order to avoid a problem where the add-in couldn't locate it's configuration files. 

    The combination of the two above is what causes the error to occur. If I remove the "file:///C:\..." from the registry setting and just use a normal "C:\..." path, the error doesn't happen even when using SharePoint Explorer view vs a server with a port number. 

    It has been deemed that we need to use port numbers if at all possible, so my followup question is: Is the any other possible way to install an add-in using VSTO SP1 and have it be compatible with SharePoint Explorer view, and keep port number usage? Is there another way to install the add-in other than click-once where it refers to the registry manifest setting each time it loads? Is there a later VSTO service pack that can help us avoid the issue?

    Any suggestions are greatly appreciated.

    Thursday, June 14, 2012 3:09 PM
  • as far as i remember 'file://' was only needed when using fast load approach. You could try to distribute your add-in through msi installer where you control what appears in registry.
    Thursday, June 14, 2012 4:36 PM
  • Hi,

    As I understand, customized port number introduced @ sign in the path, which is not valid in .NET URI class regulation. This is the root cause. To change the behavior, I would suggest you send feedback on Visual Studio uservoice. Product team will evaluate it carefully, and people vote to ideas.  http://visualstudio.uservoice.com/forums/121579-visual-studio/category/31481-net

    To set registry during solution installation, you would create msi package as Damian mentioned.  You can do that through Visual Studio setup project.

    As the issue is really a limitation in .NET base class library, so that's kind of by design.  I don't see a plan to change this behavior.

    You should have read this connect report: https://connect.microsoft.com/VisualStudio/feedback/details/729380/word-addin-pops-up-error-system-uriformatexception-invalid-uri-the-hostname-could-not-be-parsed#details

    thanks,


    Forrest Guo | MSDN Community Support | Feedback to manager

    Friday, June 15, 2012 8:39 AM
    Moderator
  • Hi Damian,

    That's actually what we are doing - we are deploying our add-in via an MSI installer that sets Word and Excel registry settings manually. The problem is, we need to use "file:///" as part of our manifest path in order to avoid the problem with VSTO 4.0 SP1 and the app.config loading issue explained in these links:

    http://connect.microsoft.com/VisualStudio/feedback/details/653444/visual-studio-sp1-or-specifically-vsto-sp1-issue-with-config-file-location

    http://blogs.msdn.com/b/vsod/archive/2011/06/14/vsto-4-0-sp1-will-cause-a-vsto-addin-to-not-find-its-config-file.aspx

    That "file:///" in combination with the @ caused by using a port number on a SharePoint site is what causes the issue for us. Remove the port, no issue. Remove the "file:///", no issue (but our add-in breaks because it can't find its local config). I'm thinking we may have to figure out a solution for our add-in that doesn't use an app.config file for settings - any other ideas would be greatly appreciated! (or if I'm missing something crucial, please slap me across the face and let me know) :)


    Friday, June 15, 2012 7:11 PM
  • My bad, I'm not aware of the issue about app.config loading until now.  For this specific part, besides ideas from people including Damian, I'm going to get other people help on it.  Please wait some time.

    with regards,


    Forrest Guo | MSDN Community Support | Feedback to manager

    Saturday, June 16, 2012 11:42 AM
    Moderator
  • As official response from VSTO is - by design, i would dump app.config and roll out my own settings txt or xml file and serialize/deserialize from it.
    Saturday, June 16, 2012 6:11 PM
  • Hi Forrest, no problem - it's a strange combination of effects. I think our solution going forward will be to get rid of app.config use in our add-in and just re-deploy it. If you do come up with any more info on this please let us know. Many thanks,


    Brad

    Monday, June 18, 2012 3:09 PM