DotNetNuke Hosting with

BLOG about DotNetNuke CMS, latest technology and Special DotNetNuke Hosting Package with

DotNetNuke Hosting With ASPHostPortal :: How I Get My DotNetNuke To Run So Fast

clock Maart 2, 2015 06:56 by author Mark

One of the most common questions that I get via the forums on this site, or via e-mail is "How do you get your sites to run so fast".  Although not perfect, my sites typically run a bit faster than your average DotNetNuke sites.  Previously I have kept the exact specifics of my changes to myself, however, with a litle encouragement from the community I have decided to share the full context of the changes that I make to a default DotNetNuke installation to get better baseline performance, as well as extra items that I do to help when I really need that "boost".


First of all I want to start out by saying that a lot of the information that is displayed here can be found in previous blog postings.  Posts such as DotNetNuke Host Settings Explained, DotNetNuke Scheduler Explained, DotNetNuke Performance Settings Explained, and Simple DotNetNuke Performance Enhancements.  Are good starting points for some of the detail behind my recommended changes.
The following changes are simply the configurations that I have found to be the best "baseline" configurations.  Consideration is needed in regards to the site setup, update frequency, traffic, hosting environment and users to ensure that you have the proper setup for your specific environment.  I will discuss the settings section by section, simply noting the changes that are made.  Please reference the specific "Detail" document for more information.
DISCLAIMER: Follow these recommendations as a guide only, I am not responsible for any effects of implementing these changes.

Host -> Host Settings Changes

The first place I visit is the Host Settings page.  There are a number of key updates and changes needed in this section.  Again, only changes are noted here.


In this section I uncheck the "Show Copyright Credits" box

Advanced -> Authentication Settings

In this section I uncheck "Enabled" for any provider that will not be used in the portal, typically the LiveId and OpenId providers

Advanced -> Performance Settings

In this section I change the "Module Caching Method" to Memory.  the "Performance Setting" to HeavyCaching.  And the "Compression Setting" to GZip Compression.

Advanced -> Other Settings

In this section I change the "Scheduler Mode" to Timer.  I enable the "Event Log Buffer" and I disable the "Auto-Sync File System" option
These are the most common Host Settings changes that I complete.  Depending on the site I'll make a few other small edits.

Host -> Scheduler Changes

The biggest change that I make here is to change the "SearchEngineScheduler" task to run typically once every 12/24 hours.  This reduces a big load on the server.

Other Changes

From a DotNetNuke configuration change that is all that I modify.  Overall those changes typically result in very noticable performance improvements, but many times it just isn't enough to keep the sites running as smooth as possible.  So depending on the situation I have a number of other items that I work with.

Regular Purging of Event Log

As most people that have used DotNetNuke have discovered the EventLog table can become a very troublesome hinderance on the performance side of a site.  Enabling the Event Log Buffer helps reduce the effects of a large EventLog, however, the best policy is to clean the EventLog on a regular basis.
I do this one of two ways.  On my own sites I have an SSIS package within SQL Server that truncates the table every 24 hours.  On client sites I utilize my Scheduled SQL Jobs module to keep a 7 day rolling history of the EventLog data.  The key here is that we MUST keep the event log small.

Skin Selection and Menu Provider

The next item of consideration is a multi-part consideration.  I focus on finding CSS based skin layouts that utilize third party menu components such as Telerik and Css NavMenu.  With a simple skin change to sites I have noticed page load times that have reduced by over 50%.
Finding a good designer that creates well laid-out skins with third party menu providers has been a key performance enhancement, at least in the page.  I have NOT benchmarked these numbers though since DNN , so the core menu provider might have better performance.

Compression/Caching Modules

As a last step, if I really need to get the most performance out of a site I will tend to lean towards Snapsis PageBlaster as a good option.  I currently use PageBlaster on this site only and have had very good luck with it, although when configuring the module you must be careful to test all functionality first.  This was another change that once implemented I noticed very visible performance improvements.


There you have it, that is my secret trick to improving DotNetNuke site performance!  Many people charge a lot of money to make these simple performance tweaks and I just laid them all out on the table for you free of charge.

Best DotNetNuke 7.4 Hosting Recommendation is the leading provider of Windows hosting and affordable DotNetNuke Hosting. DotNetNuke Hosting from provides a safe, reliable and performance-driven foundation for your DotNetNuke website. DotNetNuke is the perfect Content Management System for managing and developing your website with one of ASPHostPortal’s Hosting plans. ASPHostPortal has ability to support the latest Microsoft and ASP.NET technology, such as: WebMatrix, WebDeploy, Visual Studio 2015, .NET 5/ASP.NET 4.5.2, ASP.NET MVC 6.0/5.2, Silverlight 6 and Visual Studio Lightswitch, ASPHostPortal guarantees the highest quality product, top security, and unshakeable reliability, carefully chose high-quality servers, networking, and infrastructure equipment to ensure the utmost reliability

DotNetNuke Hosting - :: Using Master Pages and ASPX Pages in DNN

clock Januarie 9, 2015 11:06 by author Ben

In this post, we are going to see how we can add new aspx pages in DotNetNuke by re-using the existing skin designs to implement some helpfull programming in it.


If you are running a multi-portal dnn website and want to build some common pages to share between those portals, there are couple of quick ways to do that.

  • Create a new tab in portal 0 and then share link in all other portals.
  • This technique works fine when you want to show "how to" page or help page, static contents or offers related pages. You don't need any custom coding for this and it will be a matter of adding a text html module and paste the html that you designed!
  • Create a new aspx page and share link in all other portals. Well, this one also looks similar to first option but let's think about this: If you are running a multi-portal dnn site and want to show latest offers from all the portals into a page based on user's country, and users having at least 5 orders in history. Now, this will involve some quick coding to do. So, basically, if you want to show content based on some dynamic parameters like user or portal data or similar data, it will be good to create an aspx page.

There is another option! obviously you can create a new module to do this, but remember that we are not doing anything that depends on moduleId or tabId but depends on UserId or PortalId, so I believe it's a quick way to create a new page in place of building an entire dnn module.


  • Create a new theme
    Create a new theme with the name of your skin and paste your skin's css and images into it.
  • Create a new master page
    Create a new master page and paste your skin's ascx control's entire markup over there. Replace all your content pane (i.e. div or tds with runat=server) with CotentPlace holder
  • Create a new page
    • Add a new aspx page called Default2.aspx and select the new master page when creating it.
    • Go to .aspx.vb file and make your parial page class inherit from DotNetNuke.Framework.PageBase in place of System.Web.UI.Page 
    • And that's it you are ready to go!


It is really easy to add a new aspx page in dnn that is re-using skin and you will be able to access all the information like PortalSettings, UserInfo etc. Things like Tab and Module will not be there and it's obvious! This post doesn't say you should create a new aspx page in some cases or not, but demonstrates how to do it if you want. If you have some good examples WHEN we can use it or some good examples WHEN we should NOT use it, I welcome them!

This example will probably work with dnn 4.x, 5.x, 7.x, though I've used this in dnn 5.2.0 and 7.3.4.


DotNetNuke Hosting with ASPHostPortal :: How to Fix Problem DotNetNuke 7 Edit Button Not Work

clock Januarie 7, 2015 06:54 by author Mark

DotNetNuke 7 DNN Edit Button Will Not Work

After a clean install of DotNetNuke version 7.00.05, the Edit buttons would not work, and the page would repeatedly redirect to the homepage when clicking Edit. I did not experience this issue on installations which I upgraded.  I have uncovered three solutions which work, or at least work around, to solve the problem.

Method 1

One way to get around this problem is to use the Ribbon Bar instead of the Control Bar as the Control Panel setting. To make this change, navigate to the “Host” panel, click “Host Settings”, click the “Other Settings” tab. Set the “Control Panel” setting to “RibbonBar”.

Method 2

The second method, and one of the methods which actually solves the “ControlBar” issue, is to edit the web.config file. I found this solution at chaydigital. This method does work to solve the problem, but I have concerns about the waste of system resources it could cause as well as possibly creating other errors.
Open the web.config file in Notepad.exe or another editor. Find the system.webServer section, and change this section:

To this:
   <modules runAllManagedModulesForAllRequests="true" >

Method 3

Due to my concerns with placing a global fix in my web.config which might cause other errors to crop up, I decided to create two new installs on the same machine. One install was with the 7.00.05 full install package of DotNetNuke. The other install was with an older version of DotNetNuke 6 to which I applied the 7.00.05 upgrade. As suspected, in the full install website, the Edit button would not work. In the upgraded website, the Edit button worked as expected.
I decided to pull the two web.config files and compare them using a Powershell script. There were many differences in the two, but I found one difference in particular which seems to have solved my problem. The upgraded website had an entry for the FormsAuthentication module in the system.webServer section. and this entry was missing from the full install. This may be by design, I am not sure. But putting that entry in web.config on the full install version solved my issue.
Please attempt editing your web.config file at your own risk. Note that the system.webServer and modules nodes should already be there along with several other entries. The only entries you should add are in red type.

      <remove name="FormsAuthentication" />
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="" />

Hope this helps you. If you find additional solutions to the issue, let me know. I will gladly add them to the list.


DotNetNuke Hosting with ASPHostPortal :: How to Automate the Packaging of your DNN Module

clock Januarie 5, 2015 06:48 by author Mark

DotNetNuke has involved working with modules that I control, build, and have a say in. here I am set in my ways of how I like to do things, and believe that my approach to DNN module development is one of the easiest approaches to the DNN platform, because of this I have put a lot of time and effort into my Module Development Templates.
Occasionally I come across other people’s modules in my consulting work, and it tends to frustrate me when I have to do things outside of my own little “perfect module development environment”. I want to be able to switch to “Release” mode in Visual Studio and build, and have the scripts package the module I am working on so that I can easily deploy it to a customer’s development or staging environment. I had just such an experience this evening, working on customizing a module for a customer, and they had the Source to a third party module that I needed to make changes to. There is no packaging or build process anywhere inside of this module, even to the point where there are missing files in the “source” project itself.
I decided I must do something about this, so I took it upon myself to wire up my custom MSBuild scripts into the project so that I can easily build and deploy without having to go through the hoops of using the Host/Extension packaging process. Here are the steps you can use to integrate the scripts that are used in my Module Development Templates into your own existing modules (even if they weren’t built with the templates originally).

The steps below assume you are following my recommended development environment

  • Delete all source code and start over from scratch with my templates installed.
  • Open your project in Visual Studio
  • Install the MSBuildTasks project from Nuget:
    • PM> Install-Package MSBuildTasks
  • Create a BuildScripts folder in your project
  • Add two files
    • ModulePackage.targets
    • MSBuild.Community.Tasks.Targets
  • Right click on the project in Visual Studio Solution Explorer and choose “Unload Project”
  • Save changes if prompted
  • Right click on the unloaded project and choose the Edit option
  • At the bottom of the file, before the </Project> section add

<Import Project="BuildScripts\ModulePackage.Targets" />
<Target Name="AfterBuild" DependsOnTargets="PackageModule">
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />

  • Change the “CHANGEME” text to match the name of your .DNN file and the name of the ZIP file that you want the package created as.
  • Save the Project changes.
  • Right click on the project in Solution Explorer and choose Reload Project.
  • Switch into Release mode in Visual Studio and do a Build of your project.

This should create two files, and

What I typically do then is install the module to a test DNN install to make sure that everything is working correctly. You’ll want to make sure that the ZIP files created contain all the right files, and they get installed correctly, so a test installation is the best way to go through that process.
If something fails, try to track it down, then do another Build in Release mode, rinse and repeat the installation process in your test install until you get everything working properly.
Now going forward, after you do a release, you go into your AssemblyInfo file, change your version number there, and into your .DNN File and change your Version number there. Next time you build in Release mode the module will create a new VERSION number ZIP file, leaving your last version builds there as well.


We’re a company that works differently to most. Value is what we output and help our customers achieve, not how much money we put in the bank. It’s not because we are altruistic. It’s based on an even simpler principle. "Do good things, and good things will come to you".

Success for us is something that is continually experienced, not something that is reached. For us it is all about the experience – more than the journey. Life is a continual experience. We see the Internet as being an incredible amplifier to the experience of life for all of us. It can help humanity come together to explode in knowledge exploration and discussion. It is continual enlightenment of new ideas, experiences, and passions

Author Link

Corporate Address (Location)

170 W 56th Street, Suite 121
New York, NY 10019
United States

Tag cloud

Sign in