Recently I’ve been interested in incorporating more automated testing in my projects. The benefits of having tests are heavily covered in other topics so I won’t waste time explaining why I sat in on a few sessions at this year’s Code Camp NYC focusing on automated testing. Needless to say a few of the sessions was all it took to push me into getting my feet wet.
I decided to start out on a demo project just so I didn’t dirty up any formal projects while I tried out the best approach to implementing the tests. I recently created a project to check out ASP.NET Web API as a progressive download host (which allows for streaming video to iOS devices, allows downloads to be chunked and resumed by download managers, etc.) This seemed like a good candidate for tests since the behavior of the library changes based on the HTTP request headers for a resource.
(Update 2014-12-10: The code is now in GitHub and a package is available as a NuGet Package. See the announcement about it.)
Some time ago I read an interesting Stack Overflow question asking about streaming videos to iOS devices from ASP.NET MVC. In researching the answer, I learned about parsing HTTP request headers and constructing responses. In general for iOS devices to support playing video a web server needs to understand requests with the RANGE header and respond appropriately with 206 (PartialContent) and a CONTENT-RANGE header which more or less repeats the original request range.
I originally wrote an answer to this effect but also wanted to test it out to make sure it worked in ASP.NET MVC. While successful, it was not particularly elegant. After getting some feedback and requests, I wrote a second version. Surprisingly I still get pings on this from time to time and it made me wonder if something more integrated has shown up in ASP.NET MVC since my original attempts. Until recently I hadn’t had a need for this myself until a couple days ago I got the urge to stream video content from my Windows laptop to my TV and thought this might be a good time to revisit the library. What I wanted was an iOS compliant video server so I could stream videos to my Apple TV via my phone.
I knew I had a working library for ASP.NET MVC that I could have up and running in a few minutes but I was more curious if there had been any advancements in supporting partial range requests more seamlessly. A few brief searches turned up the ByteRangeStreamContent class and the HttpRequestMessage’s RANGE header used in ASP.NET Web API which looked promising.
In this post I’ll walk through replacing existing, expensive synchronous loop code with an easy to consume generic wrapper to run the code in parallel and increase performance.
I had an interesting challenge today. I was debugging a bit of code related to RSS feed item retrieval and aggregation and saw an opportunity to increase performance by multithreading my calls to different feed urls.
The code in question got List<string> urls which were links to various RSS feeds and returned a single SyndicationFeed item containing all the items from these various feeds ordered by the PublicationDate in descending order. The problem was the loop of the urls was being done one at a time and as anyone who has had to work with WebRequest and WebResponse objects knows, this can be a little costly for one request, let alone many. I knew I needed to get these requests going in parallel to cut down on all the overhead and wait time.
It’s been some time since I posted my early attempts at making parallel execution of threads easy when working with collections in .NET Framework prior to version 4. It might seem out of date but believe it or not there are a lot of developers who are still unable to take advantage of the new runtime yet. For me this is due to our strong dependence on SharePoint which unfortunately still requires the 2.0 runtime.
With this limitation strongly in place, I continue to refine my ability to work with threads.
I was debugging a problem with SharePoint 2007 Site Usage reports on a client farm and I finally figured out the problem.
Out of the box, SharePoint 2007 uses Report Viewer controls to render Site Usage reports. These reports target Report Viewer version 8 assemblies which correspond with the Visual Studio 2005 report designer. In the recent past we deployed some reports which were designed in Visual Studio 2010. To support these reports, the SharePoint web.config was modified to use the Report Viewer version 10 assemblies. This worked to get the new reports to render but a few days later it was discovered the Site Usage reports were no longer working.
(Update 2014-12-09: I’ve created a WebApi based library that leverages the System.Net.Http classes to do all the parsing. The code is very simple and much easier to support. I’d recommend trying that first. It’s a lot easier to support.)
This is to announce my new CodePlex project Resuming Action Results for ASP.NET MVC. Or MVC Resuming Actions. Or something else even more clever and catchy. Oh, and it’s already on the NuGet official feed to check out.
Some time ago I started a project called Media Streaming MVC. The project was an early attempt to give ASP.NET MVC developers the ability to easily expose dynamic, routable resources as progressive-download compliant. It was just an ActionFilter and some ActionResults with code to parse HTTP Request Headers and construct the appropriate response.
That project was developed very rapidly as a proof of concept for a StackOverflow question I had tried to answer. Over the past few months I grew increasingly unhappy with the implementation. I knew I wanted to bring it more in line with the way MVC FileResult actions were called and give it a major overhaul. Unfortunately every time I sat down to take a serious look at how I could accomplish these goals, I got overwhelmed and let my attention wander to something less challenging.
Finally I made the decision that there was really no way to clean up the project, make it easier for developers to use and retain any sort of compatibility with existing code. I made the decision to cut the cord and start fresh with the lessons I’ve learned, the feedback I’d gotten and my expanded experience with the ASP.NET MVC platform.