a few days ago I posted a some code  that (if you trust me, if you really really trust me…) you can drop into your asp.net application folders to get a quick look at the various paths returned by server.mappath or directory class and stop the nonsense with the guesswork!

Rick Strahl just posted a nice examination of ASP.NET paths, so I wanted to put them both together in one post. (ummm – that’s the one you are reading at the moment…)

Duncan Mackenzie posted a little code sample that shows the sweet syntax of

For Each cust as Customer in Customers
 …
Next

which I so very much prefer over

Dim cust as Customer
for each cust in Customers
…
next

Simple, minor, but just a nice difference. I always hated that extraneous line of code. And hated it more when we moved to vb.net and could just declare a variable and give it a value all in one line.

However! …she said with a grin.

Why stop there?

Why do I even have to (re-)define what the objects in Customers are?

Why can’t I just write

for each whateverthehecktheobjectsareinmycollection in Customers
 …
next

and have .net look at that and say “well d’uh, I know what whateverthehecktheobjectsareinmycollection is going to be because Customers is filled with Customer objects, so I will just implicitly cast the whateverthehecktheobjectsareinmycollection to a Customer.

?

Just an idea… maybe it’s already there and I haven’t discovered it yet…

Or how about if I have a generic collection of generic objects?? Oh dear, it looks like I won’t be going to bed early tonight after all… Damn!

Do you, Mr/Ms Developer, think Security is boring? Well after seeing most of the content for the DevDays web track – my answer to that is : TOUGH SHIT!

DevDays is doing a big job of trying to make this stuff accessible and palatable because it is THAT important that the secure development practices message and the HOW-TO get pushed out there.

I recognize a lot of my own mistakes in what they are trying to teach you not to do, even though I have really made an effort to do things securely.

I love my track because the first few tracks teach you about all the REASONS you need to write secure code. I get to be the knight in shining armor. Hmmmm – are there female Knights – cause I don’t know if “lady“ works for me! Anyway, I get to save the day with all of the solutions! Thanks Thom for assigning me this session!

Check the cities. See if one is near you and go!

(Darn, if only I was getting a commission! :-))

(Is this the only way to talk to you outside of the con-calls)

I wanted to point out that the DPAPI that we are talking about for protecting strings is now has a managed wrapper in Whidbey! They are still wrappers to the API, but a heck of a lot easier to code than the current solution that we will be teaching. Though the current solution is obviously what we will all need to use until Whidbey is released.

These are in the System.Security.Cryptography.ProtectedData and ProtectedMemory classes.

I plan to point this out in my talk.

I am the typical programmer who needs to hear this! Look at this post where I thought I had to do this exact thing! Thank goodness Mark Pearce corrected me immediately in the comments of that post.

This is a typical example of the points that are being made in my DevDays “ASP.NET Defenses and Countermeasures” talk.

There are a LOT of people who think that this is the solution to permission issues. Developers like me who know just enough to be dangerous! (And you thought we only said this about our end-users).

I can see that *I* am going to learn SO much from preparing for this talk. I’m already excited about sharing it.