VSTO - Outlook 2007 Add-In throwing "Could not find default endpoint element" error RRS feed

  • Question

  • I have a VSTO addin for Outlook that we have successfully installing and working for many clients.  It connects to our web services for database operations.  However, for one client, running XP and Outlook 2007, she is getting the infamous "Could not find default endpoing element " error when the add-in tries to make any web service call.

    The config file looks like this and I already verified the contract name was the same as the configuration name for the services per advice from another thread.  


    <?xml version="1.0" encoding="utf-8" ?>
            <binding name="WSHttpBinding_MSP" closeTimeout="00:01:00" openTimeout="00:01:00"
              receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false"
              transactionFlow="false" hostNameComparisonMode="StrongWildcard"
              maxBufferPoolSize="524288" maxReceivedMessageSize="5242800"
              messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
              <readerQuotas maxDepth="32" maxStringContentLength="5242800" maxArrayLength="16384"
                maxBytesPerRead="4096" maxNameTableCharCount="16384" />
              <reliableSession ordered="true" inactivityTimeout="00:10:00"
                enabled="false" />
              <security mode="TransportWithMessageCredential">
                <transport clientCredentialType="None" proxyCredentialType="None"
                  realm="" />
                <message clientCredentialType="UserName" negotiateServiceCredential="true"
                  algorithmSuite="Default" />
          <endpoint address=""
            binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MSP"
            contract="MSPCOWS.MSP" name="WSHttpBinding_MSP" />      


    Other threads have suggested that the app.config file has to be in the startup project directory which I would assume meant with the Outlook.exe?  I also saw something about the config file needing to be called app.config instead of AppName.dll.config.  None of these really suggest to me why it would work in Vista/7.0 and not XP though. 

    I could use some help!  Any ideas?

    Monday, April 25, 2011 9:08 PM

All replies

  • Hi Cindy,

    When the AddIn is working fine for other Clients - I don't think it's a problem with the config file.

    I woulod say it's a firewall-problem or the user has a Proxy-Setting in IE - so that he can't reach the Webservice.

    Can u check that?

    Greets - Helmut

    Helmut Obertanner [] []
    Tuesday, April 26, 2011 5:48 AM
  • We also thought that.  They can get to the web service url via their web browser though.
    Tuesday, April 26, 2011 1:26 PM
  • Hi Cindy,

    is there an Anti-Virus Software enabled?
    Some Anti-Virus Software requires to grant applications to access internet urls.

    Can you disable it and see if that would help? (And enable it again), Maybe check the allowed applications in the Anti-Virus software.

    Greets - Helmut

    Helmut Obertanner [] []
    Tuesday, April 26, 2011 1:58 PM
  • Hi Helmut,


    I was able to get a test computer setup that duplicates this problem.  It was formatted clean and now has Windows XP and Outlook 2007 SP2 with the Hotfix for loading VSTO addins in Office 2007.   I did not install any other software on it, including anti-virus.  The add-in loads when Outlook is started.  When the user tries to make the first call to the web services, it throws the "Could not find default endpoint element " error.

    Any suggestions on what to try on the test box at this point?


    Thanks for your help!


    Friday, April 29, 2011 4:12 PM
  • Hi Cindy,

    the only Idea that comes in my mind is to create the endpoint by code, and not reading it from the config file.
    Maybe then you can see where the error is, because you can debug then.

    Greets - Helmut

    Helmut Obertanner [] []
    Friday, April 29, 2011 4:29 PM
  • Hi Helmut,


    I created the binding and the endpoints in the code, removing the config file altogether, and it works fine now on our test machine.  I have not sent the new version to the client yet but I expect it will resolve the problem on their end as well.  If not, I will be back :)




    Monday, May 2, 2011 2:58 PM