Клиент VSTO WCF не может найти конечную точку по умолчанию при развертывании на win2k8 - PullRequest
0 голосов
/ 24 мая 2011

Я создал и развернул клиент WCF (запущенный из VSTO Word Addin) на терминальном сервере Win2008R2.При освобождении конструктор по умолчанию для прокси-сервера WCF выдается InvalidOperationException, заявляя, что конечная точка по умолчанию для контракта не может быть найдена.

Тот же клиент WCF при развертывании на машине с Win7 x64 просто отлично работает, используято же самое .dll.config

Я пытался создать экземпляр в PowerShell и получить ту же ошибку.

При создании выделенной конечной точки в PowerShell я могу извинить метод обслуживания:

$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()

Служба Web.config (часть)

<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior>
                <serviceMetadata httpGetEnabled="true"/>
                <serviceDebug includeExceptionDetailInFaults="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 (часть)

<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>

ОБНОВЛЕНИЕ

Я "исправил" это, скопировав мой Client.config в папку программ Office и переименовав его в WINWORD.EXE.config.

Ответы [ 3 ]

9 голосов
/ 18 июня 2012

Эта проблема вызвана тем, что в проекте развертывания отсутствует правильная запись в реестре для файла манифеста.Обходные решения выше работают, потому что - не найдя файл конфигурации для надстройки word / excel и т. Д., Найдите местоположение по умолчанию (каталог их программ) и найдите имя файла конфигурации по умолчанию - в случае MsWord WINWORD.EXE.config.

Неправильная форма записи манифеста:

[TARGETDIR]Addin.vsto|vstolocal

Это должно быть:

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

Тогда ваш файл конфигурации будет загружен правильно.

Для получения дополнительной информации см здесь

2 голосов
/ 24 мая 2011

Можете ли вы создать конечную точку программно?

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

Если это работает, то весьма вероятно, что проблема конфигурации.

1 голос
/ 05 января 2012

У нас была точно такая же проблема с надстройкой Excel 2010, которую мы создали с помощью Visual Studio 2010 .NET4.Мы исправили нашу проблему, следуя обновленному исправлению в этом посте, но хотели уточнить детали нашего исправления, см. Ниже.

ОБНОВЛЕНИЕ Я «исправил» это путем копированияmy Client.config в папку программ Office и переименование его в WINWORD.EXE.config.

Ниже приведены сведения о нашем исправлении:

  1. Деинсталляция нашего Excel 2010Добавить в;затем переустановил нашу надстройку Excel 2010 с помощью установщика Windows.
  2. Открыл каталог $ EXCEL_HOME .Каталог $ EXCEL_HOME - это каталог, в котором находится офисная программа Excel 2010 "Excel.exe" (для нас в Windows 7 и XP - C: \ Program Files \ Microsoft Office \ Office14 )
  3. Скопировал конфигурацию нашего приложения / надстройки "MyAddinProjName" .dll.config (которая была установлена ​​во время установки надстройки Excel) из нашего установленного местоположения надстройки ( C: \ Program Files \ Microsoft \ " MyAddinProjName " ) в каталог $ EXCEL_HOME
  4. Затем мы переименовали "MyAddinProjName " .dll.config it to" Excel.exe.config"
  5. Прыгнул от радости после того, как ошибка больше не появлялась.

Мы так и не выяснили, почему это произошло на некоторых машинах, а не на других, но мы знаем, что это исправление / обходной путь позволили нам продолжить тестирование функциональности Addin.Наше решение для обработки любых установок надстройки, которые представляют эту проблему, заключается в предоставлении сценария .bat или VB, который могут запускать системные администраторы, который будет копировать и переименовывать файл конфигурации в соответствующие местоположения.

Я надеюсь, что этоинформация помогает всем с той же проблемой и проясняет любые недостающие детали:)

...