Why isn't my custom WCF behavior extension element type being found?

Question

I have a solution that contains two projects. One project is an ASP.NET Web Application Project, and one is a class library. The web application has a project reference to the class library. Neither of these is strongly-named.

In the class library, which I'll call "Framework," I have an endpoint behavior (an IEndpointBehavior implementation) and a configuration element (a class derived from BehaviorExtensionsElement). The configuration element is so I can attach the endpoint behavior to a service via configuration.

In the web application, I have an AJAX-enabled WCF service. In web.config, I have the AJAX service configured to use my custom behavior. The system.serviceModel section of the configuration is pretty standard and looks like this:

<system.serviceModel>
 <behaviors>
  <endpointBehaviors>
   <behavior name="MyEndpointBehavior">
    <enableWebScript />
    <customEndpointBehavior />
   </behavior>
  </endpointBehaviors>
 </behaviors>
 <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
 <services>
 <service name="WebSite.AjaxService">
  <endpoint
           address=""
           behaviorConfiguration="MyEndpointBehavior"
           binding="webHttpBinding"
           contract="WebSite.AjaxService" />
  </service>
 </services>
 <extensions>
  <behaviorExtensions>
   <add
       name="customEndpointBehavior"
       type="Framework.MyBehaviorExtensionsElement, Framework, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
  </behaviorExtensions>
 </extensions>
</system.serviceModel>

At runtime, this works perfectly. The AJAX enabled WCF service correctly uses my custom configured endpoint behavior.

The problem is when I try to add a new AJAX WCF service. If I do Add -> New Item... and select "AJAX-enabled WCF Service," I can watch it add the .svc file and codebehind, but when it gets to updating the web.config file, I get this error:

The configuration file is not a valid configuration file for WCF Service Library.

The type 'Framework.MyBehaviorExtensionsElement, Framework, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' registered for extension 'customEndpointBehavior' could not be loaded.

Obviously the configuration is entirely valid since it works perfectly at runtime. If I remove the element from my behavior configuration temporarily and then add the AJAX-enabled WCF Service, everything goes without a hitch.

Unfortunately, in a larger project where we will have multiple services with various configurations, removing all of the custom behaviors temporarily is going to be error prone. While I realize I could go without using the wizard and do everything manually, not everyone can, and it'd be nice to be able to just use the product as it was meant to be used - wizards and all.

Why isn't my custom WCF behavior extension element type being found?

Updates/clarifications:

• It does work at runtime, just not design time.
• The Framework assembly is in the web project's bin folder when I attempt to add the service.
• While I could add services manually ("without configuration"), I need the out-of-the-box item template to work - that's the whole goal of the question.

I filed this issue on Microsoft Connect and it turns out you either have to put your custom configuration element in the GAC or put it in the IDE folder. They won't be fixing it, at least for now. I've posted the workaround they provided as the "answer" to this question.

Answer 1

Do you have a copy of Framework.dll with your custom behavior in the bin directory of your web project? If not that is probably the problem. Visual Studio is looking for the implementation of the behavior. Since it's listed in your config it doesn't think to look in the other projects; it expects to find the assembly in the bin.

Depending on how your project is setup, it may be able to run in debug without this assembly being put in the bin, although VS usually builds it and puts it there. But again, it depends on how things are setup.

Anyway, might just want to double check at that the assembly is available at design time.

Answer 2

Putting the assembly in the GAC would probably help, but I appreciate this isn't the answer you're looking for. Not sure where else VS will look for assemblies apart from the GAC and the directory containing devenv.exe.

Answer 3

I tried this with a new project just to make sure it wasn't your specific project/config and had the exact same issue.

Using fusion logs, it appears that the system looks for the behavior extensions ONLY in the IDE directory (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE). Copying the assembly to this directory in a post-build step works, but is ugly.

Answer 4

I've tried these and I can't get mine to work either.

Oddly enough, if you use the WCF Configuration GUI it recognizes the extension and will allow you to create it through the GUI.

In my case I still can't see the properties that I've exposed.

The example I've followed is on MSDN: http://msdn.microsoft.com/en-us/library/ms730868.aspx

Visual Studio doesn't seem to recognize that I've added a behavior extension :(

Answer 5

Per the workaround that Microsoft posted on the Connect issue I filed for this, it's a known issue and there won't be any solution for it, at least in the current release:

The reason for failing to add a new service item: When adding a new item and updating the configuration file, the system will try to load configuration file, so it will try to search and load the assembly of the cusom extension in this config file. Only in the cases that the assembly is GACed or is located in the same path as vs exe (Program Files\Microsoft Visual Studio 9.0\Common7\IDE), the system can find it. Otherwise, the error dialog will pop up and "add a new item" will fail.

I understand your pain points. Unfortunately we cannot take this change in current release. We will investigate it in later releases and try to provide a better solution then,such as providing a browse dialog to enable customers to specify the path, or better error message to indicate some work around solution, etc...

Can you try the work around in current stage: GAC your custom extension assembly or copy it to "Program Files\Microsoft Visual Studio 9.0\Common7\IDE"?

We will provide the readme to help other customers who may run into the same issue.

Unfortunately, it appears I'm out of luck on this one.

Answer 6

I try to use enableWebScript in my web config but is not recognized. Do someone had an idea about this?

Answer 7

+1. I have the same issue, and found your open ticket on MS Connect.

While designing an application architecture for a company, saying "oh by the way, here's your architecture, but you can't use Visual Studio's wizards any more, have fun!" is a hard sell.

You wouldn't think adding the current solution to the .dll search path would be such a big issue. Or even have the wizard grab the system.web/compilation/assemblies section out of the web.config and use that.

This makes me miss doing Java development... if this was a bug in Eclipse someone could just edit the source and fix it. Or if this were linux, just symlink the .dll into the IDE directory... sigh oh well...

Answer 8

As an FYI to anyone who stumbles across this these days a possible solution is to FULLY qualify your assembly in your app.config/web.config. EG if you had

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="clientCredential" type="Client.ClientCredentialElement, Client" />
        </behaviorExtensions>
    </extensions>

try - replacing the values as necassary

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="clientCredential" type="Client.ClientCredentialElement, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        </behaviorExtensions>
    </extensions>

this particular solution worked for me.

Answer 9

Yes,

I am having the same problem. It's impossible to add a WCF or a Silverlight WCF service from the IDE.

The solution that I have adopted it's very simple:

• Copy the files xxx.svc and xxx.svc.cs into new ones..
• rename them, like Service2.svc and Service2.svc.cs
• Add this new files togheter to the project

Regards, Valeriano Cossu