Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

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

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Inherit Child Applications Issue – Was it fixed in DNN 4.9.X?Inherit Child Applications Issue – Was it fixed in DNN 4.9.X?
Previous
 
Next
New Post
8/6/2009 6:08 PM
 

WELL.. We did a test where we hoped upgrading to DNN 4.9.4 would permit us to run Child DotNet applications without getting a AJAX Script Manager error from our AJAX Modules.

It appears that modifying the webconfig to allow to inherit with the simple code of <location path="." inheritInChildApplications="false"> before the <system.web> tag and at the end of the </system.web> putting </location>  to close up the code modification BREAKS AJAX SCRIPT MANAGER! and Additionally KILLS the dotnet child application as well.

This wasn't a problem in DNN 4.8.0 and WE ARE FOREVER STUCK in version 4.8.0 because we need a stable version that can function with dotnet child applications without CRASHING all the AJAX SCRIPT MODULES

WE HAVE TRIED EVERY SUGGESTION in this post and nothing fixes this problem.
Very frustraiting in deed... just would like to know exactly what was changed. We know we're not the only ones having this problem.

 
New Post
8/6/2009 7:54 PM
 

Just so we are all clear on your definition of a ".NET Child Application".

Does each child application have its own "virtual folder" and then set as an "Application" in IIS manager?

Just curious, why do you need to run these apps under the DNN application?

When I get time I'll do a few more tests.


mikez

 
New Post
8/7/2009 6:21 PM
 

 

Hi Mikez
Sorry if i was sounding frustrated... no harm meant... just trying to get this to work as it did before. And we do appreciate every suggestion posted on this issue. What we are doing with DNN is unique. And it worked for us for some time until something got changed in an upgrade that we downloaded.

For clarity here is what’s happening and why we’ve been running it this way.
We are running Virtual Directory in its own process. Doing it any other way limits the amount of traffic and there are security issues as we're running DNN completely behind one security certificate. Running our DotNet app also aids in cross process interaction on the server.
So we have to run our DotNet App as a virtual directory on the secured DNN web portal. Running them separately is NOT an option for security reasons. The requirements are Run the DNN Portal under one security certificate then run the Virtual directory on the same IIS WebSite as DNN.
Now here is where the problem arises. When we upgraded to DNN 4.9.x from DNN 4.8.0, we proceeded to carry over  our inherit Child tags in the web.config as we always did with every DNN upgrade. This however caused a problem immediately after accessing our newly upgraded portal with version 4.9.x
Some of our AJAXed modules started putting out "SCRIPT MANAGER" errors. Its as if AJAX could not be initiated from the DNN process. Also the DotNet app that was running as a child DotNet app would occasionally error out or BREAK.

You could test this very easily on your own local server. Do the following
1)Create a DNN website on IIS
2)Create a Virtual Directory for your Ajaxed DotNet App. Try something simple like hello world or something little more advanced such as a simple DotNet App that does calculations also using DotNet 2.0 in the virtual directory.
3)Insert the <location path="." inheritInChildApplications="false"> before the <system.web>tag and at the end of the </system.web> putting </location> to close it up
4)Now type in the URL or browse to your DNN 4.9.X portal and install one of your most advanced DNN modules that requires use of AJAX. Then apply that module to a page.
5)HERE IS WHERE 2 VERY BAD THINGS HAPPEN  a) You’ll get a script manager error on your DNN Page b) Now type in the
http://myipaddress/myvirtualdotnetapp and try to access it and operate it. IT crashes as well.

All we know is that this did not happen in the 4.8.0 middle ages… the middle ages where we are now stuck in and can’t get “Back To The Future” so to speak.

We know something was changed and we’re not exactly able to figure that out so we can “UNDO” that “FEATURE” which apparently showed up after 4.8.0

Hopefully we’ve added some clarity to what is happening. There were others whom were having similar issues and listed it on the support.dotnetnuke.com support web site at http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=7257&PROJID=2   and the Ticket was #7257. We never created that ticket, but when we saw it, we KNEW EXACTLY WHAT IT WAS. And never heard any solution or work-a-round.

So we've turned to the DNN forum for some help... something to give us a little hope that this can be resolved.

 
New Post
8/7/2009 6:41 PM
 

I have to say I've recently upgraded a site from 4.5.5 to 5.1.1 - in short it was fantastic. I almost choked in delight....

When I upgrade I tend to do it via a virgin install of 5.1.1 connected to the 4.5.5 database, with web.config and essential files such as portals/skins copied across. I completely cut out third party files and dll's and other mess. I then log in (I will get loads of errors because many modules will be missing) and then I upgrade to the latest module versions. Anyway if you don't get what I'm saying here you should try to use the XML merge method.

My current conclusions so far are this - Upgrade to 5.1.1 if you need to, do a test install (upgrade locally), if you do it correctly you should be very surprised on how well it went. You probably will not regret it. Those who can afford to wait or who use languages other than US should perhaps go for 5.1.2. Those starting new DNN websites should use 5.1.1 unless (perhaps) they not using US language (which case wait for 5.1.2). My personal opinion and being dead honest here.

I suggest exploring the option of getting out of the middle ages for quite some time. Do a test upgrade and see what you think....



Alex Shirley


 
New Post
8/26/2009 5:23 PM
 

Unfortunately, Upgrading to 5.x is not an option. Its no doubt we would like 5.x. The ISSUE IS We have many custom Modules that will have to be re-written to accommodate 5.X and right now we just don't have the time. Our client was very unhappy about changes made to dnn core that kills Ajax and throws us "Script Manager Errors" when trying to adjust the web config for running child dot net applications. We've tried the work-a-rounds suggested in this post. But there were inconsistent errors throughout that really "ticked" off the client so much that there was talk of changing CMS to something other than DNN. They're feeling pretty pessimistic about dnn right now and I’m just trying to keep them from changing to some other CMS application.

We're really in a world of hurt because of this added "Feature" but - HEY.... guess that’s what Growing Pains are for.

"Fun Times - Eh?"

 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Inherit Child Applications Issue – Was it fixed in DNN 4.9.X?Inherit Child Applications Issue – Was it fixed in DNN 4.9.X?


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:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. 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.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out