Howdy, I just installed dotnetnuke 5.06 on my server, say, the path is mydomain.com/dnn
I have a library independent of dotnetnuke that I have to run and it contains web services and various other httphandlers so I haven't tried to integrate it into DNN just yet. the library is located under mydomain.com/dnn/lib
The library worked fine on my old server running 5.04 and everything worked fine, but for some reason my new installation with 5.06 (windows 2008, sql server, iis 7.5) returns 404 when i try to access a page under mydomain/dnn/lib/, regardless of whether it's aspx, asmx...however images seem to work just fine, everything else either returns 404 or redirect to default.aspx in DotNetNuke. This has never happened before with my old site.
does anyone know what I'm missing here? any suggestion is be greatly appreciated.
There's was an issue introduced in DNN 5.5 that blocks those files when they're outside of the DesktopModules folder. DNN 5.6.1 fixed that to some degree (I'm fairly sure that aspx works now), but not completely. Looking at the linked issue, it may help/fix to turn off automatic portal alias mapping in your Site Settings.
Actually, the issue was fixed only in DNN 5.6.2, which is currently in beta. Version 5.6.1 still had this issue. There's a workaround that works in every situation: add the absolute url to your PortalAlias table. You'll have to do this by hand, because the Portals-tab doesn't allow aliases that root at the same level as an existing alias.
Another solution, if you can't wait for the new DNN version, includes adding the following code to the RequestFilterModule.vb and UrlRewriteModule.vb, which restores the existing behavior. This is not the fix that's applied to DNN 5.6.2, because programmers believe it is too much of a performance impact to check for file existence on every visit (which I consider odd, as several files are touched on every visit anyway, the main DNN cache uses file-based caching and in general, database access is slower than file access):
'Add this to the RequestFilterModule.vb (line #59)'
'and to UrlRewriteModule.vb (line #325)'
If File.Exists(app.Server.MapPath(Request.Url.LocalPath)) And Not _
Request.Url.LocalPath.ToLower.EndsWith(glbDefaultPage.ToLower) Then
'exit early when path is an existing path'
Exit Sub
End If
Obviously, if you apply this fix, you have to be careful with the next update of DNN.
Related
My brother's website was previously on the Streamline servers, however they recently got taken over by Fasthosts and although the front end of his still site works fine he cannot access the CMS. I've looked into this and noticed that on trying to get into the CMS an ASP 131 error message appeared highlighting disallowed parent paths.
In a conversation with the Fasthosts tech support this morning they confirmed that they do actually enable parent paths by default and that all I need to do is update the scripting path with the new one.
Since I'm not the developer of his site I didn't know, off-hand, where the scripting path would reside. I've looked through all of the files but cannot see it anywhere. Does anyone with experience in ASP have any idea where this is likely to be?
Thanks.
We're working on upgrading our site from Server 2003 running IIS6 to Server 2008 R2 running IIS7. We've been able to work through most issues thus far but have encountered one that has us stumped: .ASP pages aren't pulling in the include file that's being referenced. Here's an example:
virtual="/scripts_path.asp" -->
This is preventing our site's main menu from being pulled in. Based on what I've read on these "Interwebz," the frequent causes of this problem are ASP not being installed and ASP Parent Paths not being enabled. Unfortunately, ASP is installed and parent paths are enabled.
There have been some semi-similar questions posted here on SO but, regrettably, haven't been answered completely or just weren't relevant.
Anyone ever encountered something similar?
Now, if you'll excuse me, I'm going to go drown my sorrows... with a plate full of brownies.
try using path="C:\some\path" instead. The virtual to physical mapper is sometimes disabled. (server.mappath for example)
also the real example would be good to have.
I've just deployed my first ASP.NET MVC 2 site, and all appears to be well except I've run into an issue with IIS banning double-escaped characters, which I was relying on for a few routes.
As I don't have control over IIS (it's on a shared host) I've decided to go around the issue and replace the spaces with underscores in my URLs. Have tested and verified that this works on my local machine, and deployed the two new model classes which contain the methods that url-encode and url-decode the various bits that need this.
However, the remote website hasn't apparently noticed that I've updated the code. I've edited web.config a couple of times to try and force a recompile, deleted the remote model classes and reuploaded them, and googled around for any other reason why this would be happening. Any ideas?
Make sure you've made a xcopy to the whole site including all the assemblies that you've modified in the bin folder.
Try clearing your browser cache by pressing Ctrl+F5.
I am doing some work with Web.Routing, using it to have friendly urls and nice Rest like interfaces to a site that is essentially rendered by a single IHttpHandler. There are no webforms, the handler generates all the html/json and writes it as part of process request.
This works well for things like /Sites/Accounting for example, but I can't get it to work for the site root, i.e. '/'.
I have tried registering a route with an empty string, with 'default.aspx' (which is the empty aspx file I keep in my root folder to play nice with cassini and iis). I set RouteExistingFiles to false explicitly, but whatever I do when hitting the root url it still opens default.axpx, which has no code it inherits from, and contains a simple h1 tag to show that I've hit it.
I don't want to change the default file to redirect to a desired route, I just want the equivalent of a 'default' route that is applied when no other routes are found, similar to MVC.
For reference, the previous version of the site didn't use Web.Routing, but had a handler referenced in the web.config that was perfectly capable of intercepting requests for the root or default.aspx.
Specs: ASP.NET 3.5sp1, C#, no webforms, MVC or openrasta. Plain old IHttpHandlers.
Fixed my own problem: the issue is the integrated web server, Cassini or some such. Seems that it doesnt play nice with routing, and will by default simply return the default.aspx file or, if it is missing, show a directory listing.
Using IIS with a virtual directory works fine, but is annoying (frustrates code sharers because they need to set up new virtual directories when they open my app, and pollutes my own IIS instance. Bah. Probably what I'll do for the moment however, or setup a new application manually so I can use the domain host only path like what will exist in live.
An alternative is to use the updated version of cassini, seen here, which works if the default.aspx file is missing, but I have not worked out how to integrate it with visual studio yet. Any help would be appreciated, but its not a big priority given I have workarounds.
I realise that this is a really old post, but I just ran into the same problem using VS2012, so I'm posting this here just in case.
I solved the problem by installing IIS Express and setting the project to use IIS Express in Visual Studio. Solved the problem.
Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?