I accidentally opened up a web application project as a website. That’s not too hard to do. Just say you want to open a web site and point to the folder. It had been a while and I forgot that it was a WAP.

So I’m working on a web page and double click on a control and find myself in the markup with a new script tag and the .net code for the click event of the control. That wasn’t good considering I already had some nice event handlers for that control in my code behind.

I spent a lot of time going back and forth trying to figure out why I couldn’t get to my code behind.

I even remembered having this problem in the early days of Web App Project and the solution was to “convert to a Web Application Project” from the context menu in the solution explorer. But this option wasn’t available.

I created a new web site and looked at the page directive and noticed that in the new website the parameter pointing to the code behind file was called CodeFile, but in my old site it was CodeBehind. Wierd.

So with that clue I googled those two words, came across Steve Smith’s blog post about the opposite problem and realized my mistake!

Duh. 🙂

I finally discovered the UpdateProgress control for an easy way of getting an animated gif to display at the proper times on a page using ASP.NET AJAX. REad more…

[A New DevLife post]

Scott Gutrhie introduces his next fun project, an MVC (Model-View-Controller) Framework for ASP.NEt. Read more…

[A New DevLife post]

I’ve been using Mike Volodarsky’s patch for a while for sites that I am developing in IIS7 (no problems with file based development server) to get past debugger auto-attach problems. Now an official hotfix has been released.

Read more here

[A New DevLife post]

Recently, the VTdotNET website has been getting hit by some robot entering hyperlinks into the password text box of the login form.

ASP.NET catches this on the server side and pushes out this error:

System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (ctl00$ContentPlaceHolder1$LoginView1$Login1$Password=”<A href=http://…”).

Since I have errors emailed to me, I’m getting a LOT of these emails every day which was annoying.

So, I wanted to trap this on the client side using a validator.

While they may appear to be, login controls are not totally locked up. One of the smart tag options is to “Convert to Template”. Once you do this, you can edit the control all you want.

So I added a RegularExpressionValidator control and entered the following regex for the ValidationExpression:

^((?!href|http).)+$

which won’t allow strings that href or http. Then tied it to the password control and to the ValidationGroup for the whole login control. That way I get the validation during data entry AND when the user hits the login button.

I did the same for the User Name control.

This solved part of the problem. If you went to the actual login page, it was no longer possible to enter hyperlinks and postback. But the spam kept coming. I changed the name of the controls and put some more details in the error handler and saw that the name of the control reported in the error didn’t change and that it wasn’t even coming from the login page. But it was the ONLY login control in the entire website.

Then I got a little education from some who are less naive than I about the evil ways of spammers. Ryan Trudelle-Shwarz, Adam Sills and Dave Wanta filled out the picture for me. It’s a nasty type of comment spam where a robot collects the postback info from your site and no longer needs to return there to do the actual entry and postback. There is still some mystery here for me since there never was a login control on the home page, but as Ryan suggested, the simplest thing to do is just filter out those errors so that I don’t have to get them in my email box and forget about them.

ASP.NET Forum user keanxsoul has done some detective work along these lines and offers an interesting explanation about how the spammers are actually doing this.

Dan Wahlin and Matt Gibbs have a book just coming out about ASP.NET AJAX (Prof. Asp.NET 2.0 AJAX) from WROX. So Dan has now spent a LOT of time with AJAX and is very knowledgable. Then Silverlight comes out and boom – he’s got a Silverlight ASP.NET AJAX app that is VERY cool. I’m supposed to be writing an article on Entity Framework right now, but boy do I want to continue playing with Silverlight.

The Silverlight Beta 1.0 (golive) has a problem wtih Firefox and apparently it’s a FF bug that creates the problem. It completely prevents the embedded Silverlight app from being displayed on a web page.

Eric Sowell has a post explaining the problem and points to this MSDN forum thread which suggests a workaround which is a temporary hack.

I watched a short interview with Scott Guthrie and learned some interesting things about ASP.NET (such as it is the technology behind MySpace’s 4 BILLION page views a day)… read more…

[A New DevLife post]

There are two bumps in the road of debugging ASP.NET in Vista. The first is enabling Windows Authentication, which depends on properly installing IIS on your computer. The second is an issue with the debugger not being able to automatically attach to the process that is running your website. This is gotten around either by manually attaching each time (a huge pain in the rear that I got sick of in less than 30 minutes) or applying a quick patch that Mike Volodarsky, on Microsoft’s IIS team whipped up.

Mike’s blog post shows how to get past these bumps and more.

Joe Stagner re-recorded all of the How Do I? videos for AJAX that he had created during the Betas. Now they are all updated for the RTM version of AJAX.  THese are really valuable for getting started (and more) with AJAX. There are 23 videos. THat must have been some chore. Thanks for re-doing them, Joe.