Exception handling in DotNetNuke Container for debugging

I found another useful change in DNN core  to debug exceptions.

Function GetPortalModuleBase in Library\Components\Skins\Container.vb silently catchs exception with comment

' module was not loaded correctly

I beleive that exception should not be catched at all, because nothing return after exception causes very unclear message

“MinMax persistance type of cookie requires a ModuleId“

but at least for debugging purposes catch should be replaced with the followning code. (UPDATE 9/6/2006: It seems that the error message fixed in DNN 3.3/4.1)

Catch exc As Exception

    ' module was not loaded correctly

   Debug.Assert(False, exc.ToString)

End Try

It will make redundunt quite useful at the moment DNNDebug.aspx 

Don't forget to add to the beginning of the file the line

Imports System.Diagnostics


Update: It seems that to show exception in GetPortalModuleBase is too late.

The original exception should be shown where controls are tried to load

i.e in Default.aspx.vb -function LoadSkin() ,

\DNNLibrary\Components\Skins\Skin.vb -functions  LoadContainer and InjectModule.

I've posted this as a  suggestion to dotnetnuke support.  

Quick Start of Debugger in VS 2005 Tip required manually handle Dependencies.

Because VS 2005 seems much slower compare with VS 2003, I was very excited when read a tip , that suggested to uncheck libraries from Configuration Manager. And it really improves the speed of start up.( I don't understand why dependency check became so slow in VS 2005)

I have DotNetNuke web site project and a few library projects, both DotNetNuke and my own.

The problem happened when I changed the code in one of the libraries. It was quite obvious that I had to re-build the library which I've changed.
But the web application still used the old code. After investigation I undestood that it is required to re-build all libraries in depedencies path.

For example, your Web project depends on libraries A,B,C and D, and also C depends on B and B depends on A.

If you made changes in A, you must rebuild libraries A,B,C  for changes take affect. 



DotNetNuke NavigateURL() returns FriendlyUrls, which is not always suitable.

My DotNetNuke site  has HostSetting("UseFriendlyUrls") = "Y", which is generally good.

The most popular function used in DNN to generate url is NavigateURL.
However when I want to get Page Url and then add additional query parameters, NavigateURL() is not the best choice.
NavigateURL returns FriendlyUrl, and after adding extra parameters (e.g.
http://localhost/FSDNN/vKnowledgeDataEditing/tabid/59/Default.aspx?List=SubscriptionSearchInterest ) the structure of URL becomes different to what HttpModules.UrlRewrite expects.

HttpModules.UrlRewrite replaces TabId to -1 and appropriate page is not found.

The solution is to use = ApplicationURL(Tabid)


instead of NavigateURL and then add QueryString parameters manually.

Overloads of NavigateURL have AdditionalParameters parameter ,that probably was designed by DNN authors to add arbitrary query parameters.
It is possible to parse multiple QueryString parameters into array of string AdditionalParameters and then pass it to appropriate .Sample how to split QueryString into AdditionalParameters array of string is in DNN Default.aspx.vb InitializePage function.

Unfortunautely default FriendlyUrls implementation moves parameters into part of the path ,but default UrlRewrite HttpModule unable to restore them back.
I don't have enough experience with Rewrite rules to fix it, so using ApplicationURL is a good alternative for me.