The element 'behavior' has invalid child element 'myFaultExtension' in wcf app.config

Question

I'm trying to catch regular exceptions from a WCF service in a Silverlight client application. For that I've included the respective changes in my WCF service as given in this MSDN article.

But when I configure the behavior extension and use the same in endpoint behavior, the error mentioned above is coming up, and the service is not able to run due to this error.

I am putting here my configuration. Kindly suggest how can I solve this?

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

Touching

You might be getting this error in Visual Studio when creating the WCF config file, since the VS editor doesn't know about that extension. But does this happen at runtime as well?? How and where are you using this behavior? On the server side? On the client side? BotH? – Gers

connect.microsoft.com/VisualStudio/feedback/details/619106/… – Dynamoelectric

possible duplicate of Hearing "element 'behavior' has invalid child element" should be ignored, but prevented from updating service reference because of it – Errand

Answer 1

I had this error with my custom behavior extension that I wanted to add as an endpoint behavior. So, I edited the schema used in Visual Studio 2017 to get rid of the warning in my web.config file. It's the same warning that you received:

The element 'behavior' has invalid child element 'CustomSecurity'. List of possible elements expected: 'clientVia, callbackDebug, callbackTimeouts, clear, clientCredentials, transactedBatching, dataContractSerializer, dispatcherSynchronization, remove, synchronousReceive, webHttp, enableWebScript, endpointDiscovery, soapProcessing'.

My web.config has:

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

The CustomSecurity XML node always had the blue squiggly line underneath it in Visual Studio. It shows up as a Warning in the Error List window. I wanted to get rid of it because each time I tried to update a Service Reference, it would fail because of the warning in web.config.

So, to fix it, you'll need to edit the Schema that Visual Studio uses to validate elements. So, I opened my web.config, then selected XML on the main Visual Studio menu bar. Then select Schemas. You'll get a long list of schemas. Find "DotNetConfig.xsd" (or DotNetConfig[XX].xsd where XX is the .NET Framework version) as seen below.

Update: you might want to edit any/all xsd files with the DotNetConfig file prefix. Typically you do not want to use all of the DotNetConfigXX.xsd files at once. It's best to have the "Use this schema" option (in the Use column) turned on for only one; otherwise, you might see errors about schema elements already being defined.

Browse to the path shown in the Location column and edit the xsd file. Search for:<xs:element name="behavior" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior">

Then add a new xs:element node within the xs:choice node with the name of your custom behavior extension; in my case, CustomSecurity. Save the file and Visual Studio should validate against the new schema automatically and you should not get a warning in your web.config any longer.

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

Mazza

This approach worked for me also, in fixing a warning about cors. My project uses 4.6.1, so I edited Schemas/1033/DotNetConfig.xsd, and Schemas/DontNetConfig45.xsd (there being no 461.xsd). Seemed to do the trick. – Dichromic

I was able to build in VS 2017 without doing this, but the squiggly line was diving me nuts. Thanks! – Egon

Answer 2

This causes problems when the version of the assembly is autoincremented during assembly compile/build.

Fixed since .NET 4.0. Version/Culture/PublicKeyToken may be dropped so that the config no longer needs the autoincremented value of the version.

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

Garrett

Answer 3

I ran into this same issue. The solution for me was actually provided in the aforementioned duplicate posting Hearing "element 'behavior' has invalid child element" should be ignored, but prevented from updating service reference because of it. Turned out the 'type' field is very sensitive. Ended up using the Console.WriteLine(typeof(BetterErrorMessagesFaultBehavior).AssemblyQualifiedName); mentioned as an answer on the other post to get the exact type I needed.

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

Caracalla

@Akira: Check my answer, it may help you. – Garrett

Answer 4

Try to define your WCF in web.config with the editor to prevent mistakes. (Especially when you required to write the whole type name).

Right click on the web.config, then Edit WCF Configuration:

Then go to: Advanced --> Extensions --> behavior element extensions --> New

Then under (General) click on the left small button and choose the new behavior. It will write the full type name in the app.config for you.

Now you can see your new behavior under the <extensions> tag in the app.config with the correct type name.

Battik

Whenever I open this GUI editor, it tells me it can't find the assembly. When I add it again, save the file, close the editor and then open the GUI editor again, it says the same thing. Any clue why? – Tracey

@S.tenBrinke When you open the tool, it desalinizes the .config file and build the screens based on this data. That is to say, if there is any syntax error in your config file, it'll fail with an error message. Note that sometimes there are errors on tags that their compatible assemblies are not inside the GAC. e.g: Custom WCF Behaviors. The VS editor mark them with underlines. In that case, you must move them to the GAC or comment the tags out before open this tool. – Battik

Answer 5

iCode's solution worked for me but I had to edit all versions of DotNetCofig4x.xsd files found in ...Xml/Schemas/. x in 4x.xsd meaning 40.xsd, 45.xsd, 47.xsd and 471.xsd

Mcdavid