WCF VSTO client cannot find default endpoint when deployed on win2k8

I created and deployed a WCF client (launched from a VSTO Word Addin) on a Win2008R2 Terminal Server. When excution the default constructor of the WCF proxy an InvalidOperationException is thrown, stating that the default endpoint for the contract cannot be found.

The same WCF client when deployed to a Win7 x64 machine just runs fine using the same .dll.config

I tried to create an instance inside PowerShell and receive the same error.

If creating a dedicate endpoint in PowerShell I can excute a service method:

$binding = New-Object System.ServiceModel.BasicHttpBinding
$endpoint = New-Object System.ServiceModel.EndPointAddress("http://myserver:7777/CompanyService.svc")
$client = New-Object MyClient.CompanyServiceReference.CompanyServiceClient($binding, $endpoint)
$v = $client.Version()

Service Web.config (part)

<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior>
                <serviceMetadata httpGetEnabled="true"/>
                <serviceDebug includeException开发者_运维知识库DetailInFaults="false"/>
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <bindings>
        <basicHttpBinding>
            <binding name="NoHttpSecurity" sendTimeout="00:03:00">
                <security mode="None" />
            </binding>
        </basicHttpBinding>
    </bindings>
    <services>
        <service name="CompanyService">
            <endpoint address="http://myserver:7777/mex" contract="IMetadataExchange" binding="mexHttpBinding" />
            <endpoint name="Version" address="http://myserver:7777/Version" contract="MyService.ICompanyService" binding="basicHttpBinding" bindingConfiguration="NoHttpSecurity" />
            <endpoint name="CompanyList" address="http://myserver:7777/CompanyList" contract="MyService.ICompanyService" binding="basicHttpBinding" bindingConfiguration="NoHttpSecurity" />
        </service>
    </services>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

MyClient.dll.config (part)

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="BasicHttpBinding_ICompanyService" closeTimeout="00:01:00">
                <security mode="None">
                    <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://myserver:7777/CompanyService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICompanyService"
         contract="CompanyServiceReference.ICompanyService" name="BasicHttpBinding_ICompanyService" />
    </client>
</system.serviceModel>

UPDATE

I "fixed" this by copying my Client.config to the Office Program Folder and renaming it to WINWORD.EXE.config.

This issue is caused by the deployment project not having the correct entry in the registry for the manifest file. The workarounds above work because - having not found a config file for the add-in word/excel etc. look in the default location (their program directory) and look for the default config file name - in the case of MsWord WINWORD.EXE.config.

The incorrect form for the manifest entry is:

[TARGETDIR]Addin.vsto|vstolocal

It should be:

file:///[TARGETDIR]Addin.vsto|vstolocal

Then your config file will be loaded in correctly.

For more information see here

Can you create an endpoint programmatically?

MyProxy proxy = new MyProxy (new BasicHttpBinding(), new EndpointAddress("http://server/Service.svc"));

If this works, then very probably it is a configuration issue.

We had the exact same problem with an Excel 2010 Addin we created via Visual Studio 2010 .NET4 . We fixed our issue by following the updated fix in this post, but wanted to elaborate with the details of our fix, see below.

UPDATE I "fixed" this by copying my Client.config to the Office Program Folder and renaming it to WINWORD.EXE.config.

The details of our fix are the following:

1. Uninstalled our Excel 2010 Addin; then Reinstalled our Excel 2010 Addin via Windows Installer.
2. Opened the $EXCEL_HOME directory. The $EXCEL_HOME directory is the directory where the Excel 2010 Office Program "Excel.exe" is located (For us on Windows 7 and XP - C:\Program Files\Microsoft Office\Office14)
3. Copied our application/addin config "MyAddinProjName".dll.config (which was installed during the Excel Addin installation) from our installed Addin location (C:\Program Files\Microsoft\"MyAddinProjName") to the $EXCEL_HOME directory
4. We then renamed "MyAddinProjName".dll.config it to "Excel.exe.config"
5. Jumped for joy after the error no longer appeared.

We never figured out why this happened on some machines and not others but we do know that this fix/work around allowed us to continue testing the Addin functionality. Our solution to handle any installations of the Addin that present this problem is to provide a .bat or VB script that the System Admins can run which will copy and rename the config file to the appropriate locations.

I hope this information helps everyone with the same problem and clarifies any missing details :)