web.config conflict. - Administration and Configuration

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

Home All Forums

2/2/2006 1:29 AM

Adrian Ahrens

Joined: 11/20/2005

Posts: 9

web.config conflict.

Hi,

We are running a dotnetnuke based web-site in our root directory... c:\inetpub\wwwroot. We also have an asp-based webstore and want it to run from /webstore on top of the root folder. so it will be (url)/webstore

The problem is that the webstore has its own web.config, and it looks like the dotnetnuke's web.config is conflicting with it. So when we browse (url)/webstore we get all sorts of dotnetnuke errors, because dotnetnuke is installed in /, not /webstore, and dotnetnuke's web.config is trying to run from /webstore when we browse /webstore.

Sorry if that is confusing... I'm wondering if anyone has ever encountered this sort of issue before, and how to resolve it. If I remove dotnetnuke's web.config, the webstore works fine, but obviously the dotnetnuke site then does not.

I was told by another source that dotnetnuke's web.config would be getting appended to the webstore's, because it is a parent of the webstore in IIS. Therefore, I'm guessing that dotnetnuke stuff is trying to load in addition to the webstore stuff, and problems are arising. If this is the case, is there a way to code the webstore's web.config to ignore or remove all the dotnetnuke stuff that gets appended to it??

Any suggestions (or hacks) to get around the issue would be appreciated.

2/2/2006 9:06 AM

Michael Flanakin

michaelflanakin.com
Joined: 4/5/2004

Posts: 994

Re: web.config conflict.

I'm thinking that the problem is that the webstore app isn't set as a virtual directory. Open IIS, go to the directory's properties, and click the Create button next to the disabled Application name textbox. If this isn't the issue, then the problem is very odd, but there should be a way around it. The work-around might be long, so check that first and get back to me (read: us).

Michael Flanakin | Microsoft Consulting Services
www.michaelflanakin.com

2/2/2006 1:04 PM

David Derf

Joined: 5/18/2004

Posts: 7

Re: web.config conflict.

I just had this issue come up 2 weeks ago. Our sub application is setup in IIS [6] as an application space (has it's own bin directory). How we solved/worked around/hacked it was to copy the DotNetNuke core DLLs to the sub appliation's bin directory (/bin -> /SubApp/Bin), then add the following to the sub application's web.config at the top of the <system.web> section:

<httpModules>
<clear/>
</httpModules>

I'm sure we didn't have to copy ALL the DNN core DLLs, but we just didn't have time before go-live to play with it to figure out which ones really needed to be in the sub app's bin folder. The down side is that the sub application will need to cache all the DLLs in it's bin folder, causing the first run to load slowly (just like core DNN). BTW - we are running DNN 3.1.1.0.

2/2/2006 6:36 PM

Adrian Ahrens

Joined: 11/20/2005

Posts: 9

Re: web.config conflict.

Thankyou for your suggestions.

Flanakin, the problem is definitely not in IIS, I have tried almost everything in there. But your suggestion is appreciated :) nonetheless.

Fredevad, I've been getting help on this from the developers of the webstore, and they also suggested this.
I threw all of this extra code, just for good measure (I think all the <remove>'s are unnecessary, but my skill in xml is still a little hazy, and I wanted to make sure I remove everything - and this is the first time I have encountered the <clear/> statement )

<httpModules>
        <remove name="UrlRewrite"/>
        <remove name="Exception"/>
        <remove name="UsersOnline"/>
        <remove name="ProfilePrototype"/>
        <remove name="AnonymousIdentificationPrototype"/>
        <remove name="RoleManagerPrototype"/>
        <remove name="DNNMembership"/>
        <remove name="Personalization"/>
        <clear/>
</httpModules>

And I determined that these files needed to be copied into the /webstore/bin folder:
DotNetNuke.HttpModules.DNNMembership.dll
DotNetNuke.HttpModules.Exception.dll
DotNetNuke.HttpModules.Personalization.dll
DotNetNuke.HttpModules.UrlRewrite.dll
DotNetNuke.HttpModules.UsersOnline.dll
MemberRole.dll

Doing these things has got us further, though problems still exist... But I'm not sure now whether it is still a DotNetNuke problem, or a problem with the webstore that is independent to DotNetNuke.

I'll let you know when I have more detail.

Page 1 of 1

These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
No Flaming or Trolling.
No Profanity, Racism, or Prejudice.
Site Moderators have the final word on approving / removing a thread or post or comment.
English language posting only, please.

Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

DNN Corp. (DotNetNuke)