Das Element 'behavior' hat ein ungültiges Kindelement 'myFaultExtension' in wcf app.config

Question

Ich versuche, regelmäßige Ausnahmen von einem WCF-Dienst in einer Silverlight-Client-Anwendung zu fangen. Dazu habe ich die entsprechenden Änderungen in meinem WCF-Dienst wie angegeben vorgenommen in diesem MSDN-Artikel .

Aber wenn ich die Verhaltenserweiterung konfiguriere und dieselbe im Endpunktverhalten verwende, tritt der oben genannte Fehler auf, und der Dienst kann aufgrund dieses Fehlers nicht ausgeführt werden.

Ich stelle hier meine Konfiguration ein. Bitte schlagen Sie mir vor, wie ich das Problem lösen kann?

  <extensions>
      <!--Add a behavior extension within the service model-->
      <!-- Here SilverlightFaultBehavior is a class in AppServiceLib namespace -->
      <behaviorExtensions>
        <add name="myFaultExtension"
             type="AppServiceLib.SilverlightFaultBehavior,AppServiceLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
    </extensions>
   <endpointBehaviors>
        <behavior name="myFaultBehavior">
          <**myFaultExtension**/>
        </behavior>
   </endpointBehaviors>

Answer 1

Ich hatte diesen Fehler mit meiner benutzerdefinierten Verhaltenserweiterung, die ich als ein Endpunktverhalten hinzufügen wollte. Also habe ich das in Visual Studio 2017 verwendete Schema bearbeitet, um die Warnung in meiner web.config-Datei loszuwerden. Es ist die gleiche Warnung, die Sie erhalten haben:

Das Element 'behavior' hat ein ungültiges Kindelement 'CustomSecurity'. Liste der erwarteten möglichen Elemente: 'clientVia, callbackDebug, callbackTimeouts, clear, clientCredentials, transactedBatching, dataContractSerializer, dispatcherSynchronization, remove, synchronousReceive, webHttp, enableWebScript, endpointDiscovery, soapProcessing'.

Meine web.config hat:

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="CustomSecurity"
                type="FullyQualifiedPath.MyCustomBehaviorExtension, MyAssemblyName"/>
            </behaviorExtensions>
    </extensions>
    <endpointBehaviors>
       <behavior name="CustomServiceBehavior">
          <CustomSecurity />
       </behavior>
    </endpointBehaviors>
    <endpoint address="https://SomeServer/MyService.svc/soap"
    behaviorConfiguration="CustomServiceBehavior" binding="basicHttpBinding"
    bindingConfiguration="BasicHttpBinding_IProject" contract="ProjectService.IProject"
    name="BasicHttpBinding_IProject" />

Der CustomSecurity XML-Knoten hatte in Visual Studio immer die blaue verschnörkelte Linie darunter. Sie wird im Fenster Fehlerliste als Warnung angezeigt. Ich wollte ihn loswerden, denn jedes Mal, wenn ich versuchte, eine Dienstreferenz zu aktualisieren, schlug dies aufgrund der Warnung in web.config fehl.

Um das Problem zu beheben, müssen Sie also das Schema bearbeiten, das Visual Studio zur Validierung von Elementen verwendet . Ich öffnete also meine web.config und wählte dann XML in der Hauptmenüleiste von Visual Studio. Wählen Sie dann Schemas. Sie erhalten eine lange Liste von Schemas. Suchen Sie "DotNetConfig.xsd" (oder DotNetConfig[XX].xsd, wobei XX für die Version des .NET Frameworks steht), wie unten dargestellt.

Update: Sie sollten alle xsd-Dateien mit dem DotNetConfig-Dateipräfix bearbeiten. Normalerweise möchten Sie nicht alle DotNetConfigXX.xsd-Dateien auf einmal verwenden. Am besten ist es, wenn Sie die Option "Dieses Schema verwenden" (in der Spalte "Verwenden") nur für eine einzige Datei aktivieren; andernfalls könnten Sie Fehlermeldungen über bereits definierte Schemaelemente erhalten.

Navigieren Sie zu dem in der Spalte Speicherort angegebenen Pfad und bearbeiten Sie die xsd-Datei. Suchen Sie nach: <xs:element name="behavior" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior">

Fügen Sie dann einen neuen xs:element-Knoten innerhalb des xs:choice-Knotens mit dem Namen Ihrer benutzerdefinierten Verhaltenserweiterung hinzu; in meinem Fall CustomSecurity. Speichern Sie die Datei und Visual Studio sollte automatisch anhand des neuen Schemas validieren und Sie sollten keine Warnung mehr in Ihrer web.config erhalten.

<xs:element name="behavior" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior">
<xs:complexType>
<xs:annotation>
    <xs:documentation>The behavior element contains a collection of settings for the behavior of an endpoint.</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0" maxOccurs="unbounded">
    <xs:element name="CustomSecurity" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior/CustomSecurity">
        <xs:complexType>
            <xs:annotation>
                <xs:documentation>Specifies the behavior extension class applied to the endpoint.</xs:documentation>
            </xs:annotation>
            <xs:anyAttribute namespace="http://schemas.microsoft.com/XML-Document-Transform" processContents="strict" />
        </xs:complexType>
    </xs:element>
    <xs:element name="clientVia" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior/clientVia">
        <xs:complexType>
            <xs:annotation>
                <xs:documentation>Specifies the URI for which the transport channel should be created.</xs:documentation>
            </xs:annotation>
            <xs:attribute name="viaUri" type="xs:string" use="optional">
                <xs:annotation>
                    <xs:documentation>A string that specifies a URI that indicates the route a message should take.</xs:documentation>
                </xs:annotation>
            </xs:attribute>
            <xs:attribute name="lockAttributes" type="xs:string" use="optional" />
            <xs:attribute name="lockAllAttributesExcept" type="xs:string" use="optional" />
            <xs:attribute name="lockElements" type="xs:string" use="optional" />
            <xs:attribute name="lockAllElementsExcept" type="xs:string" use="optional" />
            <xs:attribute name="lockItem" type="boolean_Type" use="optional" />
            <xs:anyAttribute namespace="http://schemas.microsoft.com/XML-Document-Transform" processContents="strict" />
        </xs:complexType>
    </xs:element>

Answer 2

Dies führt zu Problemen, wenn die Version der Baugruppe während der Kompilierung/Erstellung der Baugruppe automatisch erhöht wird.

Behoben seit .NET 4.0. Version/Kultur/PublicKeyToken puede entfallen, so dass die Config nicht mehr den autoinkrementierten Wert der Version benötigt.

<behaviorExtensions>
    <add name="serviceKeyBehavior"  
     type="MyNamespace.ServiceKeyBehaviorExtensionElement, MyAssembly"/>
</behaviorExtensions>

Answer 3

Ich bin auf das gleiche Problem gestoßen. Die Lösung für mich war eigentlich in der oben erwähnten doppelten Posting vorgesehen Die Meldung "Element 'Verhalten' hat ungültiges untergeordnetes Element" sollte ignoriert werden, aber die Aktualisierung des Dienstverweises sollte deshalb verhindert werden . Es stellte sich heraus, dass das Feld "Typ" sehr empfindlich ist. Am Ende habe ich die Console.WriteLine(typeof(BetterErrorMessagesFaultBehavior).AssemblyQualifiedName); erwähnt als Antwort auf dem anderen Beitrag, um genau den Typ zu bekommen, den ich brauche.

    <add name="myFaultExtension"
         type="AppServiceLib.SilverlightFaultBehavior,AppServiceLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>

Answer 4

Versuchen Sie, Ihre WCF in der web.config mit dem Editor zu definieren, um Fehler zu vermeiden. (Vor allem, wenn Sie den ganzen Typnamen schreiben müssen).

Klicken Sie mit der rechten Maustaste auf die Datei web.config und dann auf WCF-Konfiguration bearbeiten:

Dann gehen Sie zu: Erweitert --> Erweiterungen --> Verhaltenselement-Erweiterungen --> Neu

Klicken Sie dann unter (Allgemein) auf die linke kleine Schaltfläche und wählen Sie das neue Verhalten. Der vollständige Typname wird für Sie in die app.config geschrieben.

Jetzt können Sie Ihr neues Verhalten unter dem <extensions> Tag in der app.config mit dem richtigen Typnamen.

Answer 5

Die Lösung von iCode hat bei mir funktioniert, aber ich musste alle Versionen der DotNetCofig4x.xsd-Dateien bearbeiten, die sich in ...Xml/Schemas/ befinden. x in 4x.xsd bedeutet 40.xsd, 45.xsd, 47.xsd und 471.xsd