CodeBehind handlers in ASP.NET

I was creating an HTTP handler for an ASP.NET project today for returning a CSV report to a customer. And naturally I wanted this to CodeBehind style as everything else. This turned out to be a small gotcha, since it is not supported out of the bag with VS.NET 2005. So for further reference here is what to do.

1. Create the handler as usual - for instance MyHandler.ashx.

2. Create a new code file for the handler - MyHandler.cs - make sure this goes in the App_Code directory otherwise it will not be compiled properly and you will get a "Could not find class: MyHandler" error.

3. Copy all code from MyHandler.ashx to the new code file, replacing all code there.

4. Add CodeBehind="~/App_Code/MyHandler.cs" to the WebHandler directive at the top of the MyHandler.ashx file.

Done deal. Why the code file has to go into the App_Code directory and cannot stay alongside the ashx-file as other handlers do is an open question. I am betting that there is some odd web.config fix for this.

Wierd ActiveRecord "bug"

As I have written earlier I am using the Castle ActiveRecord framework extensibly. It is an extremely cool framework that has cut down on the amount of database work I am doing - shortening development cycles considerably. But I am still learning, and today I finally squashed a very odd bug that had bugged me for a while.

The scenario is this: I am storing some data for the Warlocks game server in a database. This database uses the ASP.NET 2.0 Membership API to store user data as well. The part where I am at right now involves setting up some user data and then using some ActiveRecords. And for some reason this did not work.

The problem, it seemed, was that the schema for the ActiveRecords did not exist in the database. I spent several debugging sessions assuring that I had calld the "Init" method of the AbstractModelTestCase (kindly provided by Castle for making unit testing of ActiveRecords much easier) - which in turn creates the scheme. But the error was there nonetheless.

Working systematically through the test by uncommenting lines to find out what caused the error, I found out that the problem occured when I added the code that added users through the Membership class. Without that it ran fine! I tried adding a new Init call after that code, and the test worked like a charm.

So what is up here? It seems like initializing and using the Membership provider will in some way reset the database. The database is a local file database that is in the project and is copied to output - ie. the data directory. Maybe the Membership framework copies the database file again, thus overwriting the database that has had the Schema created in it. I haven't cracked it yet - but if you know what is happening, please tell me. For now I have fixed my AbstractModelTestCase to initialize the Membership framwork before creating the scheme.

If you are wondering why I am not using a database on a server, it is simply because it is much easier to use a file database so the tests can be distributed to other developers and my buildserver without setting up anything.

The Interface Tax

Evan has an OK post here, detailing the intrisics of Object Composition and Inheritance. He is very right in the way he is doing stuff, but while I was reading, something was bothering me as well. The thing that bothered me was that the code I am writing in the projects I am doing right now does not look a lot like what he is doing - and I think that I am following the OOP principles just as well as he is. So what is the difference? Actually it is that I am not "paying the Interface tax".

When I had my Advanced OOP course at ITU we really got down and dirty with using interfaces and loosely coupling everything everywhere in the programs, and for a while I followed that road in my stuff as well. But then I began to bug me that for every odd class there was an interface mirroring the methods on that class. Every time I needed new functionality in that class, I off course duly changed the interface. The great thing here is that the only class ever implementing the interface now, and propably forever, was that class that caused the interface in the first place. I call that paying the Interface tax, and in my eye it is a bad case of YAGNI.

I am not saying that interfaces are bad. They are good - for the right occasions. If you find yourself making interfaces for data entity classes, you are probably getting taxed badly. I usually only get to the point of using interfaces when making "framework stuff". Things I know will be used over and over in different projects. In an application, good old inheritance will more often be what I am after. It can save me a lot if implementation by inheriting functionality and save me the hassle of having YAGNI interfaces only being used by one class hierarchy at a time. And you can always refactor into an interface when the need arises.

So before signing up for the interface tax, remember that simplicity is King.

PS. Have you noticed the great TLA for todays topic. *DUCKING*

 

The Wii song

This is just SO much fun! SarcasticGamer.com is my new fave RSS feed. Their podcast is a hoot. Honest, no-punches-pulled opinions about the gaming hype sprikled with great radio sketch material. w00t!

Skill mastery in games

Stumbled on this interesting article from Gamasutra on the chemistry of games. Apart from presenting ideas it also tries to give a quick set of tools for evaluating your gameplay too see if it is fun, and maybe find out what is wrong with it. Worth a read, and maybe I should try it out on my Warlocks game - that BTW is getting closer to a playable state, so keep your eyes and ears open for a beta-invite. ;-) As a special treat for those who read my blog, here is the first public screenshot of the game in action. You can't wait now can you?!!! It is made with XNA using stock graphics and free sound effects. It is running on both Windows and the 360.

The Gaming BuzzMetrics

Just tuned in to Allans blog. I know Allan from ITU, having shared the experience of their enrollment course and AI course with him. He is currently employed at Infopaq. His blog is a tech blog, and there are some interesting stuff there.

While stripmining his blog, I cam across a link to the BlogPulse site, where you can make graphs displaying the trends of terms in the blogosphere, ising a technology called BuzzMetrics. Of course I had to take it for a spin in my world - so here is a chart of the Console War in the last three months.

So it seems as Wii is the most talked about console with the PS3 and MS battling for second place. Not that far from the sales figure truth. Fun to see that the E3 spike seems to have given the Wii most coverage.

BTW, my search criteria for the chart was "XBox" or "Xbox 360", "Playstation" or "PS3" and "Wii".

Old fashioned learning

Jeff Atwood brought up a subject of lerning today that made me think of the exam I just went to. The notion in his post is about how you learn to learn in college, but also touches on the subject of why todays students are not taught how to use the possibilities of the net. And it is here that my story begins.

Just recently I finished up a course in Efficient AI on ITU. It was a really good course that taught advanced algorithms in many different aspects of the field of AI. During the course we had some smaller programming assignments, and finally the course ended up in an exam. And here the timetrap suddenly clasped. The exam was a four hour written exam. Written as in paper and ball point pen. Now why is it that they can't provide us with some computers for writing our answers? I mea, we are at the Copenhagen IT-University for crying out loud! Is it because we could use the computer to solve the exam? Hardly, if they made sure no compilers were installed on the machine. Heck, if it is a logistics problem - make us bring our own machines. I mean - we were allowed to have every written note we could think of, as well as all the printed material we could carry in there with us. Might as well have brought it in electronic form and save several hectars of fine swedish forest in the process. Of course - then they could not have checked for compilers, but really - it is a course teaching algorithms used in programming, so if you are capable of writing programs to solve tre problems you were gven - is that not a display of your understanding the curriculum? Even if you brought in third party libraries, and had access to the internet you still had to have SOME clue of what they were talking about in the exam questions in order to solve the problems.

I can imagine the kinds of answers to my questions I would get if I posed them to the faculty staff. Most answers would probably be in the region of preventing cheating anf judging people fairly. And while I do acknowledge that some precautions should be taken against people shamelessly copying others work, it would not be that hard to take some electronic countermeasures against it. We are seated in a controlled environment after all. But my main problem is that I think that in the name of paranoia they are making the environment way to controlled - way too far away from an environment where the skills that are taught are to be used.

My proposition is therefore more along the lines of opening up. Giving students the tools they would normally use for the kinds of problems proposed. Yes, even the internet - logging whatever needed to satisfy big brother. The problems could then be made accordingly harder, perhaps requiring a bit of programming or a making the problems easier to solve with programming, but not impossible without. I bet that at the end you would still see the students that have paid attention during the course and prepared properly for the exam being the ones that end up with the good grades. And in the process you would have made sure that the skills related to solving problems in real life - like finding examples and articles on the net - are being kept alive and not treated as "bad stuff".

Luckily my hand got out of its cramp before I got to the celebration beers. And yes, I did get a really good grade. :)