Restless C#ding

While recreating some boilerplate code that winds up getting created for every set of apps -- including a membership provider, roles provider, etc, I initially went right for setting hashAlgorithmType based right on the enum.

More info about membership properties here.

This enum only gives three values -- MD5, SHA1, and None. The problem here is that both of those algorithms have been proven broken for some time (hopefully ASP.NET 4.0 will resolve this!). The answer of course is to use something with a little more difficulty to it... say by using SHA512Managed() and a salt. This is just another one of those times when setting values to canned possibles can be a dangerous move. This is especially true with authentication / encryption.

 

I don't know how everyone feels about pagers, and specifically about the GridView, but it's sometimes the quickest way to solve a problem. I had worked on an isolated area of an application where GridView seemed like a good fit, although the built-in paging mechanism never quite seems to fit the bill.

So I did some research, and came across this blog post by Francisco Santos, Jr., giving a very clean-looking paging system. The best parts about it are the instant notification of just how many pages are being returned, coupled with a dropdown to choose which page to actually go to. The blog post is flawed in that it never mentioned that the ImageButtons in the PagerTemplate needed to be bound to the Paginate method he declares (sometimes the best part about a blog post is the comments!), but other than thatt, the approach is good.

Also cool on his blog is a post about a script outline add-in that allows you to use Document Outline with Javascript. It's written for VS2005, so I can't guarantee it'll work for 2008.

I decided to give Jetbrains' dotTrace a try, since I had a clear need to do some performance tuning on an in-design application at work. The symptoms were down to a line in the data access area that was calling out to a service to get data that would be the same for every user. This data would change fairly unoften, and only when a new client was signed and set up.

So with that in mind, I expected to see a poor performance from the service call, and have something to measure against when I implemented a cache for the results.

What I was not expecting to find was a 2.5 second delay on every page! It turns out that a third party upload control, an HttpModule that shall remain nameless, was causing lengthy delays while reading its config properties on every ASP.NET request. The HttpModule was implemented in the main web.config for the application, resulting in even the public pages, and parts of the application that would get no gain from having the upload control's module loaded were taking the performance hit.

The simple solution was just to move the module's declaration into a lower Web.Config, in the folders where the upload was actually taking place. The moral of the story is that a) HttpModules can be dangerous (this was a situation that would've been so much better suited for an HttpHandler), and b) performance tuning tools should be a no-brainer for a developer, and can even help coding practices for things that would never normally have crossed your mind!

Lastly, dotTrace seems extremely easy to use, and I'd highly recommend it.