DotNetNuke 5.6.0 introduced a new feature that automatically creates Portal Aliases as they are needed. This feature is great for people who are developing a new site, or who are changing the domain of their site. Unfortunately there were some unintended consequences that came with this new feature. The new Automatic Portal Alias feature can interfere with custom code that is not in the traditional locations for module content.
Prior to 5.6.0 if no matching Portal Alias could be located and the request was not for Default.aspx, DotNetNuke would stop trying to process the request and just “let ASP.Net handle it”. With the introduction of the Automatic Portal Alias feature in 5.6.0 DotNetNuke no longer passed unrecognized requests to ASP.Net, but rather tried to create a valid Portal Alias for them. This change meant that various bits of custom code that are deployed in the web site, but that DotNetNuke is not explicitly aware of stopped working.
DotNetNuke 5.6.2 fixes this problem by restoring the “let ASP.Net handle it” behaviour. Because the “let ASP.Net handle it” behaviour and automatic portal alias creation disagree about what to do with an unrecognized request, the Automatic Portal Alias creation must be disabled to restore the “let ASP.Net handle it” behaviour. There is a check box in the Portal Alias section of Site Settings to Enable/Disable Automatic Portal Aliases. Automatic Portal Alias creation is always disabled on a multiple portal installation.
UrlRewriter also avoids processing certain requests and hands them directly to ASP.Net for completion out side of DotNetNuke. Previously these requests were all hard coded, 5.6.2 introduces the OmitFromRewriteProcessing host setting. When the end of the path portion of the URL (path only not query parameters etc.) matches one of the strings in this list then DotNetNuke will also “let ASP.Net handle it”. Currently this feature is meant for use by developers, there is no UI available for this setting, it can only be accessed by the Host Settings API methods.