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 );
Middleware has access to HttpContext but Filter has access to wider MVC Context which helps us to access routing data and model binding information. Filters are only part of MVC Middleware but middlewares are part of every request pipeline.
Web API includes filters to add extra logic before or after action method executes. Filters can be used to provide cross-cutting features such as logging, exception handling, performance measurement, authentication and authorization.
Action filters contain logic that is executed before and after a controller action executes. You can use an action filter, for instance, to modify the view data that a controller action returns. Result filters contain logic that is executed before and after a view result is executed.
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>
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With