Paul Wilson's .NET Blog

Well, I'm back from my vacation -- we had a great time at Discovery Cove with the dolphins, and much more.  Now I've got to figure out how to rectify my very low output, without making just wasteful posts.  I've been skimming over all the entries about Whidbey, since its mostly all old news to me.  I guess that's the downside of getting early sneak peaks, and I wrote my articles back in October for the PDC.

I'm going to be on vacation for the next week (6/26 - 7/4), and then there's always a lot to catch up on, so sorry if I don't respond to many emails (if any) or forum posts for a while.

Enough said already!

Don and Kirk have set up an Atlanta Geek Dinner on June 16th 6:00pm at Houlihan's -- I hopefully will be there.

I want to give a very special thanks to several of my subscribers for their contributions to the just released WilsonORMapper Version 2.2:

1) Paul Hatcher added support for embedded user-defined objects, which helps address some of the 1-1 concerns that have been raised -- see the demo for a working example. Paul also made some changes to the ObjectHolder, including adding a new Key property.

Craig mentions a reason to avoid links, and Eron follows up by wondering postback or links -- well here's my take:

I've got an ASP.NET website that has several IIS sub-applications running on it.  Some of the sub-apps have authentication=None and were always working fine.  I recently changed the root app to have authentication=Forms, with authorization denying anonymous users.  Several tests since that time have always shown the sub-apps still working, as expected since they are separate applications in IIS and ASP.NET.  Now all of a sudden, with no difference that I know of, one of these sub-apps started popping up the Windows Integrated Security dialog.  Looking in IIS showed that anonymous access was still granted on the folders and files of this app.  I also verified that the security permissions for all users were identical with this app and ones still working.  I changed the root app back to what it was, and that didn't fix anything, but I didn't expect it too anyhow.  Somewhere along the way in my checking, one of the other sub-apps also started having this behavior.  I don't know of anything I changed that could possibly have this behavior right in front of my very eyes!  I couldn't figure out any explanation, and therefore no fix, since the only way I know for this dialog to pop up is either anonymous denied in IIS or file/folder security settings.  My colleague finally took a web.config file from one of the working sub-apps and put it in one of the non-working apps -- and it worked!  The only difference we could find between the web.config files was that the non-working app did not have an authorization section.  Of course, it also had authentication=None, and anonymous users were allowed in IIS, so I don't see how this could matter.  We looked at the other non-working app's web.config and it was also missing the authorization section, so we added it -- and it worked too!  By the way, this authorization section simply says to allow authenticated users -- it does not even mention anonymous users.  Even if the app root were affecting this, it also allowed authenticated users except in one unrelated sub-folder, so again I don't see how this change really could help.  I've since tried removing authorization sections on a few of my local web apps and it has yet to make any difference.  Also, to the best of my knowledge, nothing in the first sub-app changed, and I know the other one quit working right before my eyes, again not touching it since it was the other one that was being checked.  I still cannot fathom why adding an authorization section, especially one that does not even mention anonymous users, could make a difference.  Anyone know of an explanation, or some other things that I should look out for that could cause the Windows login dialog to popup?

There's only 10,436 days left until my big event.