WCF / Чсла Ад

Я пытаюсь создать пробное приложение Csla 3.7/Silverlight 3 и работаю над Учебники Рокки. Это действительно простое приложение для редактирования данных одной формы/одного бизнес-объекта, и все просто замечательно вплоть до того момента, когда я пытаюсь настроить Wcf, чтобы приложение Silverlight могло взаимодействовать с порталом данных.

Ошибка, которую я получаю:

CommunicationException was unhandled by user code

An error occurred while trying to make a request to URI 'http://localhost:1406/WcfPortal.svc'. 
This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. 
You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. 
This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. 
Please see the inner exception for more details.

Я совершенно озадачен этим, так как я немного новичок в Silverlight и WCF. Моя установка довольно проста для приложения Csla Silverlight. У меня есть 4 проекта:

  • CslaSilverlight: Проект Silverlight
  • CslaSilverlight.Client: библиотека классов Silverlight
  • CslaSilverlight.Server: библиотека классов .NET
  • CslaSilverlight.Web: проект ASPNET для размещения приложения SL.

Все работает локально на моем ноутбуке под Cassini. Я хочу, чтобы DataPortal работал вне Silverlight, чтобы я мог получить доступ к SQL Server. Я думаю, что проблема может быть связана с моей конфигурацией Wcf в приложении Silverlight, которая указана в файле ServiceReferences.ClientConfig:

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IWcfPortal" maxBufferSize="65536"
                    maxReceivedMessageSize="65536" receiveTimeout="10" sendTimeout="10">
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:1406/WcfPortal.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWcfPortal"
                contract="Csla.WcfPortal.IWcfPortal" name="BasicHttpBinding_IWcfPortal" />
        </client>
    </system.serviceModel>
</configuration>

Мне интересно, важен ли номер порта, когда я меняю его, я получаю другую ошибку. Мне также интересно, правильный ли формат адреса конечной точки.

Не уверен, что это важно, но мои настройки serviceModel из ASPNet web.config:

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="WcfPortalBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service behaviorConfiguration="WcfPortalBehavior" name="Csla.Server.Hosts.Silverlight.WcfPortal">
        <endpoint address="" binding="basicHttpBinding" contract="Csla.Server.Hosts.Silverlight.IWcfPortal">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
  </system.serviceModel>

wcf silverlight csla
person Steve    schedule 16.10.2009    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Если я правильно думаю, то ошибка может сообщать вам совершенно правильную вещь: вам не хватает междоменной политики. Приложение Silverlight получает доступ к службе WCF из удаленного расположения и требует авторизации для принятия запроса.

Это произошло со мной в разработке, когда проект состоял из трех частей: приложения SL, веб-службы WCF и веб-сайта. Веб-сайт и служба WCF работают независимо, хотя и являются частью одного и того же решения. Таким образом, Cassini запускается дважды, и вы пересекаете границу.

У меня есть файл clientaccesspolicy.xml вместе с разрабатываемой веб-службой, которая имеет следующее:

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
    <policy>
        <allow-from http-request-headers="*">
            <domain uri="*"/>
        </allow-from>
        <grant-to>
            <resource path="/" include-subpaths="true"/>
        </grant-to>
    </policy>
</cross-domain-access>
</access-policy>

Файл разрешающий всем и вся, вы бы его доработали для продакшена, но в dev это был самый простой способ. Политика доступа клиента Google wcf / междоменная политика wcf - это распространенная проблема.

person Andrew    schedule 16.10.2009
comment
Звучит логично. Я погуглил, как вы предлагаете, и добавил файл clientaccesspolicy.xml в свое веб-приложение ASPNET в корневую папку, но это не имеет никакого эффекта! - person Steve; 16.10.2009
comment
У меня есть прямо в том же месте, что и файл .svc для веб-службы. Вы нашли его там? - person Andrew; 16.10.2009
comment
дох! это сработало, только один раз ... внезапно я теперь получаю Удаленный сервер вернул ошибку: NotFound Cassini запущен и работает на порту 3405. Мой адрес конечной точки localhost:3405/WcfPortal.svc - person Steve; 16.10.2009
comment
проверьте свойства вашего проекта WCF, на вкладке Интернет будут настройки cassini с точки зрения того, под каким портом должен работать ваш WCF. По умолчанию используется автоматическое назначение, что означает, что при каждом запуске он может перемещаться на другой порт. Во время разработки я просто выбираю конкретный порт и исправляю его, поскольку развертывание будет использовать что-то совершенно другое, я просто хочу знать, что служба всегда находится там, где я думаю. - person Andrew; 16.10.2009
comment
могу я спросить, что у вас есть в вашем файле .svc? У меня есть ‹%@ ServiceHost Language=C# Debug=true Service=Csla.Server.Hosts.Silverlight.WcfPortal CodeBehind=WcfPortal.svc.cs %› - person Steve; 16.10.2009
comment
Помимо разных названий службы и т. д. идентичны. - person Andrew; 16.10.2009
comment
Чтобы проверить, работает ли служба WCF, откройте файл через http, и он должен открыть страницу по умолчанию и предоставить вам ссылку для доступа к определению WSDL. Я бы сначала проверил, что он доступен/работает на порту, на котором вы его ожидаете, и т. д., прежде чем смотреть, как SL обращается к нему и где, по его мнению, он находится. - person Andrew; 16.10.2009
comment
классно. Решил это, какая-то проблема с Visual Studio. В моем веб-проекте была ссылка на Csla (net), но в папке bin была копия Csla (Light). Когда я сбросил ссылку, CslaLight снова появился в папке bin. Поэтому я удалил ссылку на Csla (net) в веб-проекте, и Csla (Net) оказалась в папке bin (вероятно, из-за других зависимостей). Теперь все хорошо и работает отлично! Спасибо за все советы... - person Steve; 16.10.2009