Special characters in path used to work RRS feed

  • Question

  • Hello,

    I have a VSTO that we install and use from a shared resource named "Base de données Access" with the special character "é".  It used to work perfectly.  Now I still can publish new versions to it and the users update well through ClickOnce, but new pcs have a WebException error "Network name not found", and the "é" character is replaced by "%E9" in the path shown in the error window!

    For testing, I created a new share "Base de donnees Access" without the accented character, and it installs properly!  I want to keep my old share name, because it is how it should be written, and it works well with everything else!

    How to make the VSTO installation work again with the special character in the path?


    Thanks, Dominic

    Friday, March 7, 2014 6:04 PM

All replies

  • Hello Dominic,

    Please take a look at the How to escape special characters correctly for a URL page. It states the following:

    Escape is using RFC2396 and updated by RFC2732 for encoding and decoding characters that are not alphanumeric (a-zA-Z_0-9 or simply \w).  Try to figure out what kind of encoding you have to use. Maybe there is an existing module.

    Also you may find the URL Decoder—Convert garbled address online utility useful.
    Friday, March 7, 2014 8:21 PM
  • Hello,

    My taught is that the OS should be doing the translation, if there is any to do.  The two computers I tried have the same regional setup.  From Windows Explorer, or the dos command "dir", are able to view the directory content properly by entering the path with the special character.

    I had one virtual computer that had the VSTO already installed.  I uninstalled, and now cannot reinstall it, it gives the same error!  The setup on my computer did not change.

    I tried the URL decoder link, which suggest to replace "é" with "%C3%A9".  I did the dos command 'dir "\\server\base de donn%C3%A9es access"' and it replied "network name not found".  I also tried with 'dir "\\server\base de donn%E9es access"' and it also replied "network name not found"!  Where is the VSTO setup taking the "%E9" from?

    Thanks, Dominic

    Monday, March 10, 2014 3:30 PM
  • Hi Dominic,

    I have reproduced this issue on my enviroment. Since it is complex, I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.

    Sorry for any inconvenience and have a nice day!

    Best regards


    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.

    Tuesday, March 11, 2014 6:01 AM
  • Sure!  Since I have a workaround, I can be VERY patient :).

    Thanks, Dominic

    Tuesday, March 11, 2014 1:12 PM
  • Hi, I just simply run as dir "\\server\Base de données Access"

    returned with no error, my OS is windows server 2008 R2 SP1

    Friday, April 4, 2014 6:17 AM
  • Hello,

    I do not think it is related to the server, but to VSTO installation package...

    Thanks, Dominic

    Friday, April 4, 2014 12:51 PM
  • hi,

    Unfortunately this is going to require more debugging. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:;en-us;offerprophone.

    Monday, April 7, 2014 12:37 AM
  • My problem with this, is that I have to pay just to report the bug.  It happens sometimes that I pay support, and it is often not so satisfactory experience.

    The phrase I've been told that just bring frustrations back is "We understand what can make you think that this is a bug", nothing can be done, and they keep the support fee!

    Since I found a workaround for now, I will not pay 300$ to report this bug, and was hoping that someone would have a suggestion.  Otherwise I will wait until Microsoft releases a fix to fix the fix that broke this in the first place.

    Thanks, Dominic

    Monday, April 7, 2014 2:52 PM