aspx, C#, mono and First Impressions

First Impressions matter, and today, I started with a blank piece of paper, and tried to port a very simple piece of code from PHP to aspx.

While you cant judge a book by it's cover, from today's experience, even reading the first few pages, was enough to make me wonder what all the fuss is with C# and ASPX, it appeared to be a poor joke in comparison to PHP.

I've hacked at C# projects before, having looked very heavily at mcs, and phpLex (a modification of csLex to generate php code). But I'd never really had any need to look at aspx. Today was a little different, a prototype I had thrown together for a project began being rebuilt in C# (dont ask why...)

The first part of the project was to get aspx + mono up and going on the debian box I was using. In general this was a matter of firing up synaptic, searching for asp.net and selecting install, and apply. There was a small issue that the default debian packages do not create a /var/www/.{cant remember the name} directory, and give it write permissions. I eventually spotted an error by starting xsp.exe manually with the verbose flag. (It would be better if xsp.exe install on debian defaulted to logging verbosely to /var/log/xsp.log)

Some of the impressions I got where from things that mono could improve on, others were a little more fundimental in terms of what at present appears to be questionable philosphy in C#, and maybe a lack of experience with aspx.

Having solved the missing directory issue, I went on to try out all the demo's that came with it, alot of these demostrate the web controls, but in general are good enough for a quick feel for the language.

I was a little perturbed by the examples of web controls, the first thing that came to mind was the template files which include <asp:input name="...."> tags would never render on a browser. It would be near impossible to send a file over to a designer and let them focus on the layout. I did like the way that the controls where available as objects (almost like DOM) to the page controller class, but there was a sense that the the base html template had to be altered far too much to enable this interaction with aspx. Ontop of this, although I'm sure it possible to avoid, I got the sense that you where running a HTML page, rather than an application that happened to render HTML. (most PHP I've done in the last year treats the HTML as a skin available to the application, and is nowhere near the page starting/running process). The example also showed only crude examples of including other files, so I'm left pondering if something as simple as a conditional include is even feasible.

But as I got my head around the task at hand, I began to see the other unusual decissions that appear to hamper productivity while developing in the language.

Class's for everything, looks like an ideal for OOP purists, but in reality, it turns simple tasks into a challenge of huge proportions, locating methods of unknown objects. The first task I set myself was sending a P3P header. Which I rather detoured into testing out sending a location header. A little googling / digging on the MSDN pages, and I discovered Response.sendHeaders(key,value). I tested this out on the page with the key=location, and tried to redirect to google.. - nothing happened.. (the browser go the header, but never redirected to anything).. A little further hunting revealed a Response.redirect() method. There was just something smelly about the idea that what should be simple, was made complex by an attempt to make it simple.

The next issue was dealing with cookies, It goes without saying that you need to know two things in PHP to deal with cookies - $_COOKIE (reading) and setcookie() (writing), in C#/aspx I had to deal with creating 2 objects to retrieve a potential cookie, I had to check it was not null, rather than just see if it was false (no native casting of null => false - eg. if (!mycookie) { .... }). and having begain to understand that I needed to use Request.cookies, I made a simple mistake of trying to use Request.cookies to save my new cookie. Again, the complexity of having Response and Request (which when skimming documentation, the difference is easily overlooked), appeared to be another case of trying to make something too simple, and yet adding complexity.

The one that really finished of the effort was looking at md5() - a nice PHP function that returns a string md5 representation of another string. While C# obviously has this, the amount of work required to do what should be a simple task appeared painful at best. Two different classes where needed , one to convert the string to a format that the md5() understood, the md5 one,  then a foreach loop to read the bytes returned and convert them back to a nice string.

Along the way I also noticed a few other counter intuative behaviours, (along with one or two slightly cuter features).

• Page exceptions without clear backtracing, and code reveal. (I think) when you try to assign values to asp form elements, that are not strings - I only got a exception, with little explaination..
• Full Page Code reveals for some exceptions, with highlighting of the offending code. (something PHP turned off by default about 2 years ago due to security concerns). - Although it help alot to have it, I'd consider it a bigger problem in the wider picture.
• Vague and often meaningless error messages. I decided to write a small function/method to do the md5 stuff, and defined the method
  public String qmd5(String in) {.....}
  I kept getting compile errors on the constructor so assumed it was something to do with String using the wrong case. - I eventually guessed that in might be a reserved word or something, and changed it to inStr and solved it..
  

The sense I walked away with today was that given this small taster, if scaled up to a larger application would mean that I would end up typing numerous variable types, and be using long object.method names for simple tasks continually, (or constantly writing simple methods to do obvious tasks. ). Constantly be fixing exceptions on typos, and trying to second guess the compiler. Probably taking up 3-4 times as much code, and not gaining any clarity of purpose in the code, compared to a project done in PHP..