Ambrosian Scripture

Real-world answers to real-world problems.

September 2004 - Posts

Your Servers are at Risk!

If you are running applications on IIS 5 or 5.1 and have not run the IIS Lockdown tool and installed URLScan, you are just asking for trouble.

Please, for the sake of your clients, self, and company, be sure to at least do these simple steps to further secure your web servers.  These things are so easy to do, you have no excuse.

While you're at it, check out the IIS 5 security checklist!


Event Handler Declarations in Whidbey

Teemu and Andy have started an interesting discussion about event handler declarations in ASP.NET Whidbey, particularly relating to VS/VWD 2005.  Since I originally voted on the bug report that started it, I thought I'd chime in with further clarification for my part.

First of all, I think I may have misunderstood what Teemu was saying when he directed me to the bug report.  I was under the impression that it was stuffing the actual handler methods inline in the ASPX (in a server-side script block) instead of in the code separation file.  Since I'm lazy (err.. efficient), I haven't bothered actually testing it out. :)  I hope we can all agree that this would be a bad thing, and that's what I was thinking when I acquiesced and voted.  I still think the report indicates that, but based on Andy's comments, I'm not so sure.

Anyways, I would still suggest that the designer can only be responsible for the initial declaration, i.e., where we first say "hey, I want to handle x event for this control."  At that point, it knows exactly where in the control hierarchy that the control is, so it should be able to correctly attach the event in code for us. 

Typically, we are talking about a top-level control, so it's a simple matter of myControl.MyEvent += new MyEventHandler(this.DoMyEvent); in the OnInit method (or Handles myControl.MyEvent, if you prefer).  However, let's say it's in a repeater template.  In that case, it can create an ItemCreated handler in which it attaches the appropriate event handler in code for each item.  In any case, if you move the control in the hierarchy after the fact, I don't think the designer should adjust it for you (simply because I tend to think it would screw up).

Having said all of that, the ASP.NET model has grown ever more towards putting controller code into the ASPX tags with this new version.  I used to be something of a purist when it comes to separating UI design from control, but I think I have to move on, since that is the direction of things.  More often than not, going with the flow makes your job easier, so instead of raging against the machine, I will just become one with the borg.  After taking that plunge, it is easy to see that letting ASP.NET parse out my event handler hookups is the easier way to go.  At least, if we can't agree on anything else, we should be consistent.

Posted: Sep 15 2004, 11:32 AM by Ambrose | with no comments
Filed under:
VS Live! Community Lounge

Just a heads up to VS Live attendees.  If you have any problems that have been bugging you for a while, or if you just want to hang out, stop by the "community lounge" in the exhibition hall and have a chat.  The times are as follows:

Monday, Sep 13, 2004: 12:30 pm – 4:00 pm
Tuesday, Sep 14, 2004: 12:00 pm – 3:00 pm and 6:00 pm – 8:00 pm (Evening Reception)
Wednesday, Sep 15, 2004: 11:00 am – 2:00 pm

Hope to see you there!

Pimp My Ride!
So I finally took the plunge and forked over the dough for some custom rims on my 6th generation Celica (much better looking than the 7th!).  After a few hours, the look of the ride is sooo much nicer.  Check it out here!
Posted: Sep 12 2004, 07:08 PM by Ambrose | with no comments
Filed under:
OT: Ambrose and Frances Get Acquainted

So I'm actually in the worst of the hurricane so far (here where I live).  Winds up to 60mph, they say.  I guess I'm lucky, being in a newer part of town, new apartments, and right near big power lines, so I haven't lost power yet.  In any case, it's pretty amazing seeing the strong winds blowing the rain and trees around.  A little earlier, I braved the storm to bring you some on-location coverage [Download  ~1MB Movie].  You can see the wind starting to pick up a bit, but the video doesn't really do it justice.  Being here in the midst of it, it really is impressive.

Of course, in any case, I'm not seeing the worst of Frances, and thankfully, she seems to not be doing so much damage as Charley.  She's a lot bigger and slower, but the winds aren't nearly so bad.  I don't want to make light of it for those who are losing badly in all this, but I think a lot of people are relieved.  Nonetheless, there is still a lot of need, so if you feel moved to help the many people in Florida hurt by these last two hurricanes, you can help out here.  Many companies, like my employer, are matching donations to help out the victims.

Posted: Sep 05 2004, 04:47 PM by Ambrose | with no comments
Filed under: ,
.NET 1.1 SP1 Killed my ASP.NET

Okay, so like a good Microsoft lover I install the service packs as soon as they're available if not before.  I installed 1.1 SP1 to address a remoting bug.  But now my ASP.NET apps don't run.  I have to ask: Microsoft, where's the love?  I give and give and this is what I get in return!?

Seriously, though, I'm getting Server Application Unavailable and Event Viewer reports:
Event Type:     Error
Event Source:   ASP.NET 1.1.4322.0
Event Category: None
Event ID:       1007
Date:           9/1/2004
Time:           4:11:23 PM
User:           N/A
Computer:       AMBROSE
aspnet_wp.exe could not be launched because the username and/or password supplied in the processModel section of the config file are invalid.


Event Type:     Error
Event Source:   ASP.NET 1.1.4322.0
Event Category: None
Event ID:       1084
Date:           9/1/2004
Time:           4:11:23 PM
User:           N/A
Computer:       AMBROSE
aspnet_wp.exe could not be started. The error code for the failure is 80004005. This error can be caused when the worker process account has insufficient rights to read the .NET Framework files. Please ensure
that the .NET Framework is correctly installed and that the ACLs on the installation directory allow access to the configured account.

Now, I thought, oh, they just reset the ASPNET account password, and since I'm using the "trusted subsystem model" with mirrored passwords, I have to reset it.  So I went and set the ASPNET account password to the same used in my processModel element.  No dice.

...time flies as I bang my head against a wall thinking "ARGH!  They do too match!!"...

Well, it turns out that the ASPNET account got locked out.  I guess my domain policy here gets applied to local accounts.  I unlocked it and reset IIS, and voila, we're back in business.

Now, wouldn't it be nice if the service pack didn't reset the ASPNET account password?  I think it's pretty safe to assume that someone applying a service pack already has installed ASP.NET, so it is not necessary to reset/recreate that account.  Microsoft, please update your tools to not muck with my settings, especially when they're settings that you recommend in your PAG books.

More Posts