Find a post...

To our second installment on this two part series on handlers and modules in ASP.NET web applications, their significance and how to begin debugging situations where things have gone haywire. Like I mentioned in the previous post on handlers: modules and handlers go together like peas and carrots. The main difference is the following: whereas a handler runs only when ASP.NET has decided it should handle the incoming request and ASP.NET stops after it has found the handler, the module always runs on every request and ASP.NET continues. So the way that looks is that upon a web request ASP.NET first passes the request to each and every module in the list of modules and then tries to find a handler for it and passes the request on. Most crucially a module can alter a request as it passes through it or set the stage for other components before they run. For the remainder of this post I assume you will have seen/read through the previous post and you are familiar with Fiddler, web requests a ...

This post is the first of a two part series about handlers and modules and is an attempt to offload what I know about handlers to you. Knowing what handlers are and how they work is what separates the savvy from the not-so-savvy when it comes to IIS administration. Although very few modules in the DotNetNuke ecosystem use/rely on handlers, those that do experience a steady stream of support calls along the lines of “hey, XYZ doesn’t work” and it is down to a handler issue. Examples of modules that use handlers are Ultra Video Gallery and Document Exchange. DotNetNuke uses handlers itself as well. So what is a handler? In a nutshell a handler is piece of code that handles a web request. To understand why it’s good to know more about this you need to look closer at http traffic (i.e. the bits and bytes that go back and forth between your browser and the server).

Things are getting where they're supposed to be. While we finish the site please hang around, click your way through the communty and let us know your findings.

This article is about the use of templates in DotNetNuke modules, specifically the new Blog module. The aim is to provide some background to those interested as to why I chose the templating mechanism that I did. And how it works.

I can think of two reasons why you’d be a DNN Platform addict. Either you think it’s an awesome tool to make some money or you think you can make some money using this. I’m kidding. There is a second group. Those that itch to work on something bigger than they would otherwise be able to work on, together with some of the sharpest programming minds on the planet. Obviously I’m not excluding you’re here for both reasons. But the focus of this post is on the second group. Those that have been bitten by the Open Source bug.

I’m happy to announce a new release of the one and only “official” DNN Blog module. And it’s not just some new tweaks here, some bugfixes there. It’s a complete rewrite of this module. I know. That sounds crazy. And it is. But there were some good reasons to do this. In this blog post I’ll elaborate on those reasons and some of the highlights of the new module.

This blogpost is about disk permissions and asp.net applications like DotNetNuke. Although there are probably many posts like this I write this because permissions, or more precisely the lack of them, are the root cause of many support requests. And a little knowledge is all that would have been needed to avoid the situation.