HttpContext.Response.Filter

问题:

Currently using asp.net mvc 3 VS 2010. Just installed VS 2013 and now our custom filter is not working. When the page is rendered it just displays a blank page. The filter has data and writes it out but something in the chaining process is not working.

var response = filterContext.HttpContext.Response;
response.Filter = new MappingResponse(response.Filter);

In visual studio 2010 the filter is System.Web.HttpResponseStreamFilterSink.

In visual studio 2013 the filter is Microsoft.VisualStudio.Web.PageInspector.Runtime.Tracing.ArteryFilter

Cannot even find that class in the docs. It seems like it is not chaining the Write method when I call the stream class.

This is the actual code where I write out the stream

var responseBuffer = UTF8Encoding.UTF8.GetBytes( htmlPage );
responseStream.Write( responseBuffer, 0, responseBuffer.Length );

回答1:

After a long digging around I noticed that VS2013 come with a new addition; SignalR - which as it turns out is associated with the ArteryFilter problem.

So, in order to solve this problem, uncheck the "Enable Browser Link" feature next to your Debug button and voila; filters works as expected again. Still weird that VS2013 does not chain filters.

Also, note that this is a general ASP.NET feature and hence not limited to MVC.

PRESERVED FOR HISTORY - ANSWER IS ABOVE

I am experiencing the same thing but so far it seems related to the new IISExpress and not VS2013 perse. What worked fine in VS2012 suffers the same fate as the one introduced by installing VS2013.

When executed through normal IIS the problem disappears, hence your code is working fine. Let me know if you find a way to disable this {Microsoft.VisualStudio.Web.PageInspector.Runtime.Tracing.ArteryFilter}.

Further investigation shows that the applicationhost.config (typically located in %USERPROFILE%\documents\IISexpress\config) indeed is changed by VS2013. I have a backup renamed to ApplicationHost.config.20120825120333.bak. The solution to this mystery is somehow hidden within this configuration change.

A direct restore of the config make IISExpress unable to start from VS2013.

ONE NOT-SO-GOOD SOLUTION:

You can turn debug off (equivalent to CTRL+F5), and IISExpress will act and work as expected. Enabling debug will once again introduce the feature that this entry is about.

  <system.web>
    <compilation targetFramework="4.5" debug="false"/>
    <httpRuntime targetFramework="4.5"/>
  </system.web>

回答2:

We just hit this issue in VS 2015.

To add to Michael's answer, the most elegant solution IMHO is to disable browser link feature in web.config, so it works for all developers without additional manual step.

<appSettings>
    <add key="vs:EnableBrowserLink" value="false"/>
</appSettings>

More details on the feature and how to disable it @http://www.asp.net/visual-studio/overview/2013/using-browser-link#disabling