Well, from my last post the full install Wiki was indeed Wiki ... just a bit more involved.  A Scenic Route Wiki, if you will.

Now, I get a 500.19 error about duplicate key entries in the System.webServer tag area.  Per this very handy link, a <clear/> tag does handle this area: http://stackoverflow.com/questions/782252/avoid-web-config-inheritance-in-child-web-application-using-inheritinchildapplic/782277#782277, you have to look for Nick Cecil's entry further down.

This handled, the NEXT 500.19 error comes up, next shot.

Next 500.19 Error: Nick states in his answer "While <clear /> may work for some configuration sections, there are some that instead require a <remove name="..."> directive, and still others don't seem to support either. In these situations, it's probably appropriate to set inheritChildApplications="false"."

Well, wrapping this section with

<location path="." inheritInChildApplications="false"> ... </location>

or putting in a <Clear/> tag just below <modules>, lastly trying the <remove name: ... option, had to be done several times:

Honestly, the old procedure is FAR more comprehensive.  I'm now rolling along with the usual and customary web.config errors that are iatrogenic or have to be Googled.  So I'm on "home turf" and have just hit the connection strings area ... question and I don't mean to be critical but it's 10:09PM, I get up at 5:00AM for my real job and I just have to ask ... Why is such a simple thing as setting up the connection strings left out of the procedure? Sure "we all know that" but since it wasn't there, I'm thinking it MIGHT be part of the wizard to enter it and maybe this can be typed in at that point?  Nope ... it should have been entered into the procedure.

I do have to really enlarge text to make it easy to read ... possible I overlooked that line because I like larger text. (I'm 61 in May ... too much info, I know)

OK, the questions are I'm SURE there's an easy way to avoid all this web.config hell.  Surely there's a procedure for 7.x (this is 5.x era).  Where might it be?

Richard,

Thanks for the input.  This is installed as its own site, not as a child of another site.  See my post at this link for some more input (and so I don't have to copy it all over here! :) ): http://www.dnnsoftware.com/forums/forumid/107/postid/498876/scope/posts#498876

I have always installed source because it's handy to have it.  On most of the DNN work I've done, I've leveraged existing DNN modules for ideas on customizing.  In all the times I've installed source, this has NEVER come up.  Not even once from the early 3.x versions all the way up to now.

Oddly, the production sites were upgraded to 6.2 easily.  I copied the most recent production site in order to set up a Dev site to move to 7.x and this is where the fun began.  I ran into skin issues on the upgraded dev site.  I'm at the point where I am now to circumvent this.  Specifically, on the upgraded Dev site, I was able to set up Dark Knight just fine to show the client that a responsive skin would work.  We have to get set up for responsive sites like last week.

I put in a trial skin we wanted to look at and found that after this, host and admin navigation would not work.  To zero in on the issue, I restored the site to Dark Knight and tried to change the skin to Gravity -- tried to work with just DNN provided responsive skins.  No go ... once I changed one skin to another did not have Host or Admin nav capability.  I could type in the pages like admin/useraccounts or host/hostsettings in the URL bar and get to them but could not do anything once there.

After proving I could duplicate the malfunction,  I put up a post to get this resolved.  Understandably, no one's replied to it because they have not seen that either. :)

My best guess is -- we had a 5.x skin version from a certain company installed that had some issues.  I think something related to this skin corrupted the site.  I did remove this after upgrading the site to 7.x and this is when I set up Dark Knight for Host and Admin skins.  However, per the manufacturer these skins won't work on 7.x.  Their newer versions do but we need a responsive skin.

The obvious work around, since the data we need is in our own tables in our current site and just needs, for instance, UserIDs and Portal IDs from DNN, is to just do a 7.x install and then script over our tables, views, other db objects and we're good to go.

Except I have all these issues.  That's quite a bit of data.  Any help you can give is appreciated.

Roger on the wrong inheritance and I think that may be it.  How it happens I don't understand but an important clue it might be happening is ...

This was just sent to our ISP.  We're trying to get IIS configured and / or rule it out.  Note, this is its own site in IIS as shown here:

Each site has its own app pool and its own DNN install but note the other sites, which are working and all of which upgraded to 6.2 run with the Network Service, not via a designated App Pool.  I did try changing the NewDevDNNVIS to Network Service just on a lark but of course, this didn't fix anything.

Well, it would seem if there were a machine.config issue on a higher level something wrong would be showing up on all our sites.  This isn't the case, as mentioned, they all smoothly upgraded to 6.2.

So ... WHERE could this brand new install possibly be inheriting from?  Understanding the concepts of inheritance regarding config files is something I don't have a grasp on.  Enlighten me if that's the issue but I'm thinking that somehow these 2 sites are Siamese twins.

Thanks,

Mike