2011-01-18 2 views
3

При попытке удалить ссылки «tempuri» из файла wsdl. Я следовал всем существующим советам, о которых я могу думать. Добавьте атрибутWCF4 хостинг в IIS, WSDL: bindingNamespace никогда не читается

[ServiceBehavior(Namespace="mynamespace")] 

к реализации класса, Добавить

[ServiceContract(Namespace="mynamespace")] 

к интерфейсу контракта и изменить атрибут «bindingNamespace» для конечной точки в web.config, чтобы соответствовать. Но при загрузке (в IIS) пространство имен имен никогда не меняется. Его ВСЕГДА tempuri.

Есть ли у кого-нибудь другие мысли по устранению этой проблемы? Ниже приведен образец из веб-конфигурации ... имя_связанного пространства никогда, независимо от того, что я делаю, обновляется, чтобы быть mynamespace, его всегда tempuri.org. Если после загрузки конечных точек через фабрику хоста я повторяю привязки в описании хоста и обновляю их, они будут меняться, но это похоже на взлом.

для обслуживания по адресу: «http://mydomain.com/MyService.svc» следующее представляет конфигурацию конечной точки, может ли это даже использоваться IIS?

<services> 
    <service name="ServiceImplementationClassReference,MyAssembly" > 
    <endpoint name="" 
       address="MyService.svc" 
       binding="basicHttpBinding" 
       bindingNamespace="mynamespace" 
       bindingConfiguration="" 
       contract="IMyContract" /> 

    <endpoint name="mexHttpBinding" 
       address="mex" 
       binding="mexHttpBinding" 
       contract="IMetadataExchange" />   
    </service> 
</services> 

Relavent куски сгенерированного файла WSDL, который до сих пор ссылаются tempuri.org

<wsdl:import namespace="http://tempuri.org/" location="http://mydomain.org/MyService.svc?wsdl=wsdl0" /> 

........

<wsdl:service name="Directory"> 
    <wsdl:port name="BasicHttpBinding_IDirectoryServices" 
    binding="i0:BasicHttpBinding_IDirectoryServices"> 
     <soap:address location="http://mydomain.org/MyService.svc" /> 
    </wsdl:port> 
    </wsdl:service> 

в WSDL: узел определения пространства имен XML, i0 (как указано в приведенной выше службе) также устанавливается на tempuri.org, следовательно, необходимость в заявке на импорт. Нет изменений в использовании temprui, если я использую BasicHttpBinding или wsHttpBinding. Фактически, установка привязки к wsHttpBinding в файле web.config по-прежнему приводит к выходу выше, ссылаясь на BasicHttpBinding_IdirectoryServices.

Спасибо!

+0

Ladislav, Yes this is .NET 4.0; Я добавил соответствующие части файла wsdl, надеюсь, это поможет. Все дело в том, что можно смело писать правильно. Я был бы более чем счастлив, чтобы отправить все, что может показаться полезным. Благодаря!! Я ценю вашу помощь. – Kevin

ответ

9

Похоже, известная проблема: https://connect.microsoft.com/wcf/feedback/details/583163/endpoint-bindingnamespace?wa=wsignin1.0

Вот измельчить моего web.config. Обратите внимание, что я ограничивающее мое использование для HTTPS, поэтому YMMV с тем, что вам, возможно, потребуется сделать следующее:

<behaviors> 
     <endpointBehaviors> 
      <behavior name="Secure" /> 
     </endpointBehaviors> 
     <serviceBehaviors> 
      <behavior name="MetadataBehavior"> 
       <serviceMetadata httpsGetEnabled="true" /> 
       <serviceDebug includeExceptionDetailInFaults="true" /> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <services> 
     <service name="Company.Services.Implementation.Service" behaviorConfiguration="MetadataBehavior"> 
      <endpoint address="" behaviorConfiguration="Secure" 
         binding="basicHttpBinding" bindingConfiguration="httpsBinding" bindingNamespace="http://services.company.com" 
         contract="Company.Services.Interfaces.IService" /> 
      <endpoint address="mex" behaviorConfiguration="Secure" 
         binding="mexHttpsBinding" bindingConfiguration="httpsBinding" bindingNamespace="http://services.company.com" 
         contract="IMetadataExchange" /> 
     </service> 
    </services> 
    <bindings> 
     <basicHttpBinding> 
      <binding name="httpsBinding"> 
       <security mode="Transport" /> 
      </binding> 
     </basicHttpBinding> 
     <mexHttpsBinding> 
      <binding name="httpsBinding" /> 
     </mexHttpsBinding> 
    </bindings> 

Вот код-мудрое решение от Raffaele Rialdi (немного изменен мной):

/// <summary> 
/// Attribute which will add a binding namespace to every endpoint it's used in. 
/// </summary> 
[AttributeUsage(AttributeTargets.Class)] 
public sealed class BindingNamespaceBehaviorAttribute : Attribute, IServiceBehavior 
{ 
    /// <summary> 
    /// The binding namespace; 
    /// </summary> 
    private readonly string bindingNamespace; 

    /// <summary> 
    /// Initializes a new instance of the <see cref="BindingNamespaceBehaviorAttribute"/> class. 
    /// </summary> 
    /// <param name="bindingNamespace">The binding namespace.</param> 
    public BindingNamespaceBehaviorAttribute(string bindingNamespace) 
    { 
     this.bindingNamespace = bindingNamespace; 
    } 

    /// <summary> 
    /// Gets the binding namespace. 
    /// </summary> 
    /// <value>The binding namespace.</value> 
    public string BindingNamespace 
    { 
     get 
     { 
      return this.bindingNamespace; 
     } 
    } 

    /// <summary> 
    /// Provides the ability to pass custom data to binding elements to support the contract implementation. 
    /// </summary> 
    /// <param name="serviceDescription">The service description of the service.</param> 
    /// <param name="serviceHostBase">The host of the service.</param> 
    /// <param name="endpoints">The service endpoints.</param> 
    /// <param name="bindingParameters">Custom objects to which binding elements have access.</param> 
    public void AddBindingParameters(
     ServiceDescription serviceDescription, 
     ServiceHostBase serviceHostBase, 
     Collection<ServiceEndpoint> endpoints, 
     BindingParameterCollection bindingParameters) 
    { 
    } 

    /// <summary> 
    /// Provides the ability to change run-time property values or insert custom extension objects such as error 
    /// handlers, message or parameter interceptors, security extensions, and other custom extension objects. 
    /// </summary> 
    /// <param name="serviceDescription">The service description.</param> 
    /// <param name="serviceHostBase">The host that is currently being built.</param> 
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) 
    { 
    } 

    /// <summary> 
    /// Provides the ability to inspect the service host and the service description to confirm that the service 
    /// can run successfully. 
    /// </summary> 
    /// <param name="serviceDescription">The service description.</param> 
    /// <param name="serviceHostBase">The service host that is currently being constructed.</param> 
    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) 
    { 
     if (serviceHostBase == null) 
     { 
      throw new ArgumentNullException("serviceHostBase"); 
     } 

     foreach (var endpoint in serviceHostBase.Description.Endpoints) 
     { 
      endpoint.Binding.Namespace = this.bindingNamespace; 
     } 
    } 
} 

использование:

[ServiceBehavior(Namespace = "http://schemas.vevy.com/Printing")] 
[BindingNamespaceBehavior("http://schemas.vevy.com/Printing")] 
public class LabelsService : ILabelsService 
{ 
    // ... 
} 
+0

Удивительный, по крайней мере, есть причина! Спасибо, Джесси, я не думал там смотреть, я не ожидал, что это ошибка в архитектуре. – Kevin

+0

Хотя мне любопытно, почему узел , кажется, вообще не читается. Например, я могу удалить ссылку на конечную точку mex, и служба по-прежнему обслуживает данные wsdl без каких-либо проблем, если у меня есть поведение службы, определенное с пустым именем.Удаление пустого имени, чтобы сделать его именованным экземпляром, отключает метаданные, но применяя этот именованный экземпляр, поскольку поведениеConfigruation для ничего не делает. Как будто упрощенная конфигурация WCF 4 не переопределяется элементами в web.config =/ – Kevin

+0

Дальнейшие исследования говорят, что это по умолчанию: http://msdn.microsoft.com/en-us/library/ee358768. aspx Как обойти это, чтобы заставить IIS использовать настраиваемые конечные точки web.config, является единственным способом реализовать пользовательский хост за пределами IIS? – Kevin

Смежные вопросы