I just read on DotNetKicks that apparently Visual Studio 2003 is not going to be officially supported in Vista.  Allow me to say: Double-ewe.  Tee.  Eff.

I'm floored by this.  Supposedly, though, it will only break debugging in VS2K3, since the security model has been reworked significantly.  Note to self:  Install VS2K3 on my Vista box and try to break it.

If this is true, I suppose one could develop in VS2K5 and compile the MSIL in .NET 1.1 with MSBee.

I had a site where I was wanting to store some configuration data in web.config, but the problem is that the data was a little more complex than standard name-value pairs.  As it turns out, this is a rather common problem, and is easily mitigated by building custom handlers to parse the sections.  Some examples are here.

What I ended up doing was writing a handler to just pass back the XmlSection.  Then it can be cast as an XmlNode, and you can use SelectNodes or any number of classes, like XPathNavigator or XmlTextReader, to parse it.

    publicclass XmlSectionHandler : IConfigurationSectionHandler
    {
        public XmlSectionHandler(){}

        publicobject Create(object parent, object configContext, System.Xml.XmlNode section)
        {
            return section;
        }
    }

It's not terribly unlike what this guy is doing, but he uses XmlSerializer to just deserialize the whole section so he doesn't even need to parse the XML.

I've been trying to get an internal Commerce Bank DotNetNuke portal going.  The idea is that everyone on my team has enough projects, we don't need to be devoting man-hours to putting together minor internal websites when a content management system would do the job.

According to the DNN installation whitepaper, the basic installation is just a virtual directory in IIS, with a SQL authenticated data connection.  This would never fly with our DBAs, as they insist on Windows Authentication on all new projects.  No big deal, says I.  We'll just set up a Windows domain account with the proper rights in SQL Server, add <identity impersonate="true" userName="domain\account" password="password" /> to web.config, change the SQL connection string to reflect this change, and we'll be golden.  Well, not so much.

See, everything in DNN seemed to run fine, with the exception of the scheduler.  The scheduler is the part of DNN responsible for purging old data and indexing the site for search.  I read the scheduler whitepaper, and there was nothing in it other than some very basic concepts.  I Googled every term I could think of relating to DNN and scheduling, but found nothing related to my issue.

I finally decided to try running DNN in its own App Pool under the new Windows account.  To be honest, I've never really had much of a need to run anything under anything other than DefaultAppPool.  I created the new App Pool, assigned the virtual directory to it, pointed FireFox at it, and got nothing but "Service Unavailable."  D'oh!  Wonder what's up with that?  A little Google work found this gem.  The TechNet link is dead, but he gives enough detail to figure it out.  As he describes, I added my account to IIS_WPG and verified it had the other permissions he mentioned, fired off a resetiis, and everything was fine.

So I suppose what was going on behind the scenes had to do with DefaultAppPool running as Network Service, my DNN application running as my Windows account, and between the two of them not being able to launch the scheduler thread.  I feel a little silly having spent more than a day on this.  Why couldn't I find any information to lead me to the conclusion that I needed to run in a different App Pool?  Why did I have to dig and dig and experiment to figure this out?  Why couldn't there be something in the scheduling whitepaper that describes the permissions associated with scheduling?  Is this indicative of my own lack of knowledge, or is this something anyone might stumble into?  While I adore DNN as a project, I think it really needs some updated, in-depth documentation.