net, aspnet comments edit

For reasons I won’t get into, we recently ended up with a scenario in MVC where we needed to use RenderAction to get some data into a view. Some of the data was exposed via async calls to services.

The challenge is that RenderAction doesn’t support asynchronous controller actions. To accomplish the task, we ended up with a synchronous controller action that used Task.Run to get data from certain async calls. And, yeah, I know that’s not really the greatest thing in the world but there wasn’t a great way around that.

That landed us with a new challenge: HttpContext.Current was null in the Task.Run action but not in the partial view the controller action returned.

Normally that wouldn’t bother me, a service call not having a web request context, but due to a certain chain of logic (again, which I won’t get into) we had a call to DependencyResolver.Current in the asynchronous action. We’re using Autofac, which creates a lifetime scope per web request, but without any request context – explosions.

In the end, we had two solutions.

The first solution manually set the call context in the asynchronous task.

var context = System.Web.HttpContext.Current;
return Task.Run(() =>
    CallContext.HostContext = context;
    return this.AsyncCallThatReturnsTask();

That worked in some simple cases, but for some reason it didn’t stick in certain chained async/await calls down the stack.

The second solution was to rewrite certain things to be synchronous and only make async calls on things that don’t need HttpContext. That’s sort of a cop-out, but we couldn’t really find a way around it without getting… really, really deep. This is where we actually ended up.

I have a feeling there is something more that could be done by cloning bits of the current SynchronizationContext and/or ExecutionContext, setting up a custom TaskFactory, and firing up the async calls through that, but given the problem we’re solving is sort of a one-off and the high risk of deadlock or something crazy breaking under load…  it wasn’t worth diving that deep.

It would be nice if MVC would support asynchronous RenderAction calls, though.

halloween, costumes comments edit

Record year this year despite Halloween being on a weekday. The weather was pretty nice, which I’m guessing made it more amenable to be out, but otherwise I’m not sure why we got such a boost. We even shut down half an hour early - at 8:00p instead of 8:30p - to get Phoenix to bed. (We had a couple of kids knock after we shut the lights off, so you see those in that final time block.)

2013: 298

Cumulative data:

</tr> </thead> </table> The costume this year was a BioShock splicer. ![Travis as a splicer]( Jenn didn't get her costume done, but is working on a splicer costume for the Halloween party we're attending this weekend. Phoenix was, at various points, a fairy; a princess; and Merida from *Brave*. People in general were much more pleasant this year, but it probably helped that Phoenix was the one handing out the candy most of the time. It's hard to be pissed off with a two year old fairy putting candy in your bag. Even the older kids who are usually sort of belligerent got really friendly. Plus, Phoe had a great time with it and talked to all of them like they were best friends. This was also Phoe's first trick-or-treat year. She went to Jenn's work, my mom's work, and my work; and she also ran up and down our block. There's more candy at our house than we know what to do with, and she had a total blast.
2006 2007</th> 2008</th> 2009 2010 2011 2012 2013
Time Block 6:00p - 6:30p 52 5 14 17 19 31 -- 28
6:30p - 7:00p 59 45 71 51 77 80 -- 72
7:00p - 7:30p 35 39 82 72 76 53 -- 113
7:30p - 8:00p 16 25 45 82 48 25 -- 80
8:00p - 8:30p 0 21 25 21 39 0 -- 5
  Total 162 139 237 243 259 189 -- 298

net, ndepend comments edit

I’ve been using NDepend for a while – since version 2.7 – and each release is always noticeably better than the last. Version 4 last year brought with it some of the best stuff with CQLinq and seemed to focus a lot on enhancing the internals and technical usefulness. The latest version, version 5, focuses on the UI and the general user experience.

The NDepend site actually has a great overview of the new features, and Patrick Smacchia has a sort of case study explaining the UI enhancements, so I suggest you check those out.

The UI enhancements are immediately apparent when you fire up the application.

NDepend 5 startup

Everything is a lot cleaner and more modern feeling. You don’t realize how much of an impact that has on it until you’re actually using it.

Things are generally much easier to find and figuring out “what to do next” after running analysis isn’t nearly as challenging as it used to be. My complaint from version 4 about the UI being a bit confusing is pretty much gone. The updated menus combined with the dashboard screen (see below) have pretty well solved that issue.

The two coolest improvements that immediately caught my eye were the new dashboard and the update to the HTML report format.

On running the analysis, you are now presented with a dashboard screen that has several metrics and trend graphs. Particularly from a long-term reporting standpoint, these trend graphs are fantastic. You can track how the application is changing over time and very easily communicate that in a visual format. (My screen shot below doesn’t show trends because I only ran it once but you see where they’d go and so on.)

The new NDepend dashboard screen with trend

You can customize that dashboard to your heart’s content – every graph has a little set of editing buttons that let you customize and the definitions for those are all stored along with the project.

The HTML report is now also much cleaner. It offers the same great level of detail, but the presentation is such that it’s not all on One Gigantic Page.

HTML report from

The navigation menu on the side slides out when you mouseover and that’s how you get to the detailed info.

NDepend report

One really cool internal enhancement is that you can define what JustMyCode means so your queries over JustMyCode are more precise. You do this by prefixing your query with notmycode like:

from a in Application.Assemblies where
select new { a, a.NbILInstructions }

That way when you query over JustMyCode you get a more specific set of results:

// This will behave based on your definition of JustMyCode
warnif count > 0 from t in JustMyCode.Types where
t.NbLinesOfCode > 500
orderby t.NbLinesOfCode descending
select new { t, t.NbLinesOfCode }

Really slick.

I mentioned to Patrick that it would be nice to be able to define “named code sets” in a similar fashion and reuse those in other queries. In my case, I have a fairly large application, but some of the application assemblies that I want analyzed shouldn’t be counted against the application in coverage analysis. There’s no way to exclude full assemblies from coverage reporting easily because there are several queries that define the metrics – you’d have to copy/paste the “where” clauses across all of them and keep them in sync. Instead, it’d be cool if you could do something similar to the JustMyCode thing where you could define a named set of code (e.g., the set of assemblies on which I want coverage analysis) and then reuse that named set in coverage queries – update the definition once, all the coverage queries get updated.

My number one issue with NDepend still persists to version 5 – you still can’t use environment variables in framework folder paths. Just as in version 4, this is sort of a showstopper when it comes to running NDepend in server farms as part of your build process where the Windows folder and Program Files folder are potentially not on the same drive on every server.

Regardless, NDepend 5 is definitely worth the upgrade. It’s clean and modern, much easier to use, the reports are easier to navigate, and it remains one of the more valuable tools in my toolbox. Head over to NDepend and check it out. The base of overview videos and documentation has been constantly growing so you can actually see it in action doing pretty much anything.

Full disclosure: I got a free personal license from Patrick at NDepend. However, we have also purchased several licenses at work and make use of it to great benefit.

General Ramblings comments edit

I admit, I have sort of a love-hate relationship with my toddler. I love her so much and she’s so cute and friendly and fun… when she’s in a good mood. When she’s in a bad mood, or doing her “testing boundaries” thing, I want to throttle her.

Where I’m going with that is that I look for things that we can both enjoy together – activities we can sort of “bond” over, where we’re both having a good time. Sometimes this means racing hippity-hop balls around the house, but I can’t really run around for hours (or let her ride my back for hours) like she wants, so finding “quieter” activities is good.

Jenn usually gives Phoe her phone on the way home from day care so Phoe can pick whatever she wants to watch from Netflix. Phoe has now taken to watching Doctor Who of her own volition. She’ll scroll around and look for it.

So the new quiet activity now is watchingDoctor Who together. “Daddy, I watch Doctor with you. We watch Doctor together.” Yes, yes we will.

I’ll get her a cup of juice, get myself a Coke or something, and we’ll sit down and watch an episode. She’ll reach her cup over and go, “Cheers!” and we’ll clink together and drink.

She likes to point out the characters. “That’s the Doctor, Daddy.” Yes, that’s the Doctor. “That’s Martha. She doctor, too.” Yes, Martha’s a doctor, too, but not the same kind of doctor. (We’re heading out of third season into fourth.) “Oh, Daddy, he bad guy. Doctor need stop the bad guy.” The Doctor will get him, honey. You know he will. “Cheers!” *clink*

And when one episode ends: “We watch that again, Daddy!” Good girl. My job here is done.