Tag: DotNetNuke

My thanks go out to Mitchel Sellers for informing me that DotNetNuke has a bulk install feature. I had a need to modify an existing Windows service so it could silently update some DNN modules. I was able to make it work in this same service a couple years ago by modifying the DNN 4.3 source code to allow the main DotNetNuke.dll library to function outside of a web application (no easy feat, that). From there I could use the PaInstaller class to load a module. But then it wouldn’t work against 4.9.0 portals.

When I tried to do the same thing with the 4.9.0 source, it failed miserably. It just wouldn’t create an instance of SqlDataProvider, no matter how much I coaxed it. The better way was to have my service download the new module files (zips) to the install/module folder under the portal’s root, create an HttpWebRequest to http://mysite/install/install.aspx?mode=installresources, then parse the response to check for success.

The response parsing was easier than I thought it would be. I did the bulk update first using a web browser so I could see what I was dealing with. The HTML itself was nice in that it put non-blank space elements between each module name and result, so I could use Split() to break everything out. I ignored the first two elements of the resultant array since it contained all the unimportant stuff before the list of modules, then simply looped over the array and verified the word Success was in each even-numbered element, like so:

I’m not sure why I had never heard of this feature over the course of developing several custom DNN modules, even though I’ve spent untold hours sifting through the forums at dotnetnuke.com and the Internet at large for detailed information on the portal’s architecture. In any case, that was the one new thing I learned that day.


The DotNetNuke Client API has always seemed mysterious and confusing to me, so much so that I phased it out of a module I wrote a while back in favor of an AJAX web service. But there are certain parts that are useful, namely the ability to store values on the server side for use on the client side, and vice-versa. I recently ran into an issue using it that fortunately was simple to fix. I have a module that will be accessed anonymously, with no user login at all. I was having trouble using the DNN namespace in client script because the browser said it couldn’t find it, which didn’t make any sense at all. Somewhere during the login process all the namespaces get exposed, because once I logged in things worked as expected.

The key was calling DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference in Page_Load of the page where I was trying to use the API. The API documentation mentions that routine, but the context was such that I only expected to need to call it if I was using a version of DNN prior to 4.0 (I had 4.9.0) In any case, it’s fixed and the module development continues apace. My thanks go to Jon Henning, creator of the API, for the tip.