none
How is a WebException in Outlook add-in resolved by deleting invalid TypeLib entry? RRS feed

  • Question

  • Hi All,

    I have a weird issue.

    First, a quick background: We have an Outlook add-in that connects to our servers and updates a PST file stored on the client (NOT their primary PST - not that its relevant here). Supported in Outlook 2003 to 2016, written in C# and uses Redemption too. Connects to the server via SOAP Web Service requests to ASMX pages.

    Recently one of our clients complained that the Add-in cannot connect to the server. And sure enough there are errors logged when connecting to the server. The exception thrown is a WebException with the message "The underlying connection was closed: An unexpected error occurred on a send.", with an inner exception of type IOException and the message "The handshake failed due to an unexpected packet format." at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request).

    I would assume this is something to do with their network, maybe missing proxy credentials, or outdated proxy configuration, etc..

    But it turns out that the client's IT tried out an older resolution we had provided to them for another issue, and that resolved it!

    The issue was that the client machine had upgraded its Office/Outlook version recently and there were registry entries to an invalid version. And this is the resolution given was to locate and delete the invalid TypeLib entry under HCR. https://www.fieldstonsoftware.com/support/support_gsyncit_8002801D.shtml

    Now the client is saying that deleting the invalid registry key resolved this (unexpected packet format) issue as well.

    What I would like to know is, has anyone else come across this? Does anyone know how the two are related and why that solution works? For the life of me, I cannot see a connection...

    As always, any thoughts are much appreciated!

    Thanks!

    Friday, May 6, 2016 8:33 AM

Answers

  • Hi Edward,

    Thanks for the response, but that did not give me any answers at all.

    Gonna file this under "unresolved conundrums" and move on...I hope it won't come back down the line to cause issues...

    Thanks all for your help anyways!

    Monday, July 25, 2016 1:49 AM

All replies

  • Hi Thimila,

    >> An unexpected error occurred on a send.", with an inner exception of type IOException and the message "The handshake failed due to an unexpected packet format." at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request).

    How did your add in connect to server and how did you use GetWebResponse? Could you share us which step and code cause this error?

    Based on your link, it seems outlook upgrade set the version reference for the TypeLib entry to a incorrect value.

    Best Regards,

    Edward


    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, May 9, 2016 2:18 AM
  • Hi Edward,

    Thanks for your reply.

    My application is developed using C# on .NET 4.0. I add the reference to the Web Service wsdl (it's a asmx web service). Then I connect to the web service using the .NET auto-generated classes and the method signatures. So in MY code, it is only a single step that goes somewhat like this:

    using(WebServiceClass xx= new WebServiceClass())
    {
       xx.Url = "appropriate Url based on server client should connect";
       DataTable zz = xx.GetInformationMethod(param1, param2, param3);
    }

    Yes, the registry entry defined in the link is pointing to the Outlook upgrade messing up the typelib reference. What I am trying to find out is how is the invalid typelib connected to the web service call failing?

    Cheers!

    Monday, May 9, 2016 2:58 AM
  • Hello Fernando,

    I don't think these issues are related to each other. Did you try to run a standalone application with the same web service call on a problematic machine before correcting the windows registry keys? Do you get the same results in that case?

    Also make sure all the required prerequisites were installed before the add-in is loaded (including the full edition of the .Net framework, not Client Profile). 

    Which interop version do you use in the project? Are interop types embedded?


    [custom.development]

    Monday, May 9, 2016 9:36 AM
  • Hi Eugene,

    Thank you for the reply.

    No, unfortunately I was not able to run any tests/diagnostics on the affected machine (there was only one as far as I am aware), as they had gone and modified the registry by the time we scheduled a screen share.

    The full version of the framework is installed as a pre-requisite to my add-in during the install process itself, so I am certain that is OK.

    The Visual Studio project references the Office and Microsoft.Office.Interop.Outlook 15.0.0.0 assemblies.  I do embed the interop types - I think: the property 'Embed Interop Types' for both the assemblies is set to true.

    I would have thought that the issues are not related as well - if not for the fact that the client's claims... and now their IT want to know why as well. :P

    Tuesday, May 10, 2016 7:45 AM
  • Hi Thimila,

    Is there a pc you could get WebException error? If there is, I suggest you create a simple outlook add in without SOAP Web Service requests to check whether this issue still exist. If it did not exist, I suggest you uninstall your original add in, and reinstall it to check whether this issue still exist.

    Best Regards,

    Edward


    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, May 11, 2016 5:57 AM
  • Try to use external PIA assemblies, not embed them into the add-in assembly.

    [custom.development]

    Wednesday, May 11, 2016 3:29 PM
  • Hi Eugene,

    Thanks for your reply. Could you tell me what difference this would make? From my understanding, NOT embedding my PIAs means that my add-in will be using the PIA installed on the client machine, correct?

    That means that if they do not have them installed, it will fail outright?

    And in the case above where they have incorrect registry entries to their TypeLib, wouldn't my add-in fail to load as well?

    Thanks!

    Monday, May 16, 2016 1:56 AM
  • Hi Thimila,

    Now, you assume your issue is related with TypeLib registry. I suggest you compare the difference of TypeLib Registry in work and non-word pcs. And also, I suggest you backup your TypeLib Registry before you upgrade outlook and then compare TypeLib Registry after you upgrade outlook.

    Best Regards,

    Edward


    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, May 16, 2016 5:57 AM
  • Hi Edward,

    Thanks for the response, but that did not give me any answers at all.

    Gonna file this under "unresolved conundrums" and move on...I hope it won't come back down the line to cause issues...

    Thanks all for your help anyways!

    Monday, July 25, 2016 1:49 AM