Cool Dude Programmer I have just begun working on an application, a website which offers people paid subscriptions via PayPal to a weekly message, which they can view on the site after logging in. I had the site designed, including the CSS and two separate master pages. The site was up on staging as an ASP.NET 2.0 Web Application Project written in C#, and I had just started looking to the required functionality when I got an unexpected lesson in the differences between the two ASP.NET development models; that is, the "Web Site" and the "Web Application Project" models.

Quick note on naming conventions: I always use the single-word version, "website"; personal choice. Microsoft refers to the ASP.NET template as "Web Site", as in FILE -> New Web Site. Still, if you look at the Drop Down Menu names in Visual Studio after opting to go with a "Web Site", you will see "Website". Worse still, try googling this! Consistency aside, this is one dumb-ass naming choice which is right up there with MOSS "Features", another joy to Google... end of rant ;-)

I normally use the Web Application Project model because it is what I am used to and it makes sense to me. I have always viewed the Web Site model as something to use for demonstration purposes and the like. Truthfully, when Microsoft initially brought out only the Web Site template with VS 2005 and then did the turnaround to also include the Web Application Project template in SP1, I believe that at this point they should have dropped the Web Site model completely. To this day, it leads to nothing but confusion among developers of all levels.

The differences between the two models have been pretty well covered, or at least so I thought. This article is not going to delve into the details of these templates, so for the benefit of those new to ASP.NET, here are some informative references on the two models:

* Comparing Web Site Projects and Web Application Projects
* Visual Studio 2005 Web Application Project Option
* ASP.NET 2.0 - Web Site vs Web Application
* Converting a Web Site Project to a Web Application Project
* Add a Reference to a Visual Studio Project in a Web Site

 With a two-week deadline, I wanted as much out-of-the-box functionality as I could leverage from ASP.NET.

Surprise #1: Profiles only Work Out-of-the-Box with the Web Site Template
In order to implement the logic for the application described above, I planned on using User Profiles to store some extra information for each subscriber such as the date they subscribed along with the type of subscription. Profiles allow you to store some extra information per user when using the ASP.NET membership system. In this case, I was using SQL Server 2005 to store membership details. Profiles are stored in the database automatically and all we have to do is add this extra information to our web.config file. We don't need to know anything about how this data is stored or retrieved.

What they don't tell you is that Profiles only work out-of-the-box with the Web Site option. I discovered this while reading the comments on Scott Guthrie's great blog posting on this topic. There is a workaround available and you can find out more about that here. The problem stems from the fact the Web Application Project does not have the Profile object automatically added to each page as with the Web Site project, so we cannot get strongly-typed programmatic access to the profile properties defined in our web.config file.

The Web Project workaround did not appeal to me because this is an E-Commerce site for a client and I did not like the idea of having to resort to an add-in. I had no way of knowing how stable this was or what other issues might have arisen within my short project time-frame. You can code your own custom profile class if you choose.

The real kicker here is that Profiles are still not available out-of-the-box with the VS 2008 ASP.NET 3.5 Web Application Project template. A mysterious omission...

Surprise #2: Where is the Web Content Form in the Web Site Project?
As already mentioned, I was using two separate master pages and every page in my site is based off one of these master pages. When I went to add a Web Content Form in the Web Site "project", there was none! At first I hand-coded the page tag, then I noticed the "Select master page" checkbox. The images below show the Web Content Form when using a Web Application Project and the lack of one when using the Web Site "Project".

Web Application Project - Web Content Form


Web Site Project - No Web Content Form


Surprise #3: Where have all the Namespaces Gone?
No namespaces are used for classes anywhere in the App_Code folder. Now, most of us already know that the application automagically finds classes placed in this folder. But, for someone like me who is so used to working with the project model, this didn't strike me right off the bat! So, presumably name conflicts are not a cause for concern here? This is confirmation that Microsoft never intended the Web Site "Project" template for enterprise work, if anyone was ever in any doubt.

My own project will have a user control which is referenced from a master page. On reading this post by Rick Strahl, I see that there are all kinds of difficulties when accessing user controls with the Web Site model - read through the comments. Now I'm thinking that I may revert to the Web Application Project and use the Web Profile Builder to solve my Profile issues after all! At least I won't have grapple with trying to dynamically load a user control from a different assembly... are you getting the bad code smell yet?

Web Server Attacks From the Washington Post, April 25, 2008:

Quote... Hundreds of thousands of Web sites - including several at the United Nations and in the U.K. government -- have been hacked recently and seeded with code that tries to exploit security flaws in Microsoft Windows to install malicious software on visitors' machines. Unquote...

Apparently there have been an estimated half-million attacks on different Web sites this week alone. There seems to have been a rush to judgement in trying to point the finger of blame at a recent Microsoft Security Advisory (951306). According to Bill Staples, Product Unit Manager for IIS, "Microsoft has investigated these reports and determined that the attacks are not related to the recent Microsoft Security Advisory (951306) or any known security issues related to IIS 6.0, ASP, ASP.Net or Microsoft SQL technologies."

These attacks are not related to said security advisory but are aimed at sites, on any platform, that are open to SQL Injection. What we are really seeing is a growth in SQL Injection over other types of attack. Although around for a long time now, this technique has been gaining in popularity among hackers over the last couple of years, and seems to be more popular now than cross-site scripting or buffer overflow exploits. I would argue that this would not be the case for ASP.NET sites if basic input validation and SQL parameters in combination with stored procedures were employed, as is the recommended practice.

At the very least, even if you are still using ASP and haven't time to convert to stored procedures, check your input data! All input data is evil and when designing your application you should take time to consider where else that input may be coming from, such as query parameters, cookies, etc. Watch this space...


Debugging ASP.NET - Irish Style

by admin 2. April 2008 19:09

Irish Aplomb I work in a fairly relaxed development environment. I guess you could call it RAD. Most Web development work is Rapid Application Development by nature anyway. That said, I'm not totally ignorant of the newer methodologies such as Test Driven Development (TDD). However, all the tools and methodologies in existence will not make the slightest bit of difference if your mindset and approach are out of whack for the job at hand.

10 Rules for Debugging - Irish Style

1) Keep it simple, stupid (KISS principle). Many people get in a bind because when given a choice between a simple solution and one that seems more elegant, they of course go for the latter. Elegant code is achieved through experience and refactoring. Get it working first!

2) Divide and conquer. Why look for a needle in two haystacks? Narrow it down.

3) Don't let your emotions get the better of your thinking - always a recipe for disaster.

4) Never panic. Only wimps panic. In the face of insurmountable odds, get drunk, read Hemingway and proclaim your genius loudly to all.

5) Your brain works productively for 40 minutes at a time. This is a universal rule and you are not different. At the 40 minute bell, go away from your desk for 10 minutes as you're only going downhill from that point on. For some strange reason, most people cannot accept this fact. Look around you at work to see who the idiots are. "Gee, I'm sure to get promoted if I never leave my desk"... and pigs will fly.

6) Do not presume that the first change you make to your code that makes it run, is the actual solution. You may have been looking at a symptom...

7) There's a reason why error messages are neither friendly nor helpful. If the guys who penned them were shining beacons of descriptive prose, they would be working for the New Yorker instead of doing that job in the first place. Guess how they get their kicks? Never rely on your bog-standard error message clueing you in to anything other than the onset of an early ulcer.

8) Learn how to think, if you haven't already. I was in my 30's before I started asking the right questions about anything, let alone software development. Ask someone what they really want in life and 90% of the lemmings will reply that "they want to be happy". See where I'm going with this?

9) Creativity is your number one asset. Be creative and learn how to develop new synaptic pathways in that grey matter. The brain needs to be exercised in different ways, regularly. Get out of bed on a different side tomorrow and put your clothes on in a different order. If you really want a laugh, do everything in the washroom with the opposite hand to the one you normally use.

10) As for ASP.NET, if you don't know the life cycle inside-out, you shouldn't be wasting your time skipping a chapter to debugging in the first place ;-)