DotNetNuke Hosting with

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

DotNetNuke 7 Hosting - with :: How to Building an Ecommerce in DotNetNuke Module

clock February 24, 2014 06:04 by author Kenny

DotNetNuke is a program that runs on Microsoft ASP.NET. It is also a framework, meaning, it is a program that is designed to be extended. One of the ways you extend the framework is to create modules. These modules are installed inside a DotNetNuke installation and when they run in that DotNetNuke installation they extend the framework to create a DotNetNuke website also called a portal.

In this article I will tell you about “How to Building an Ecommerce in DotNetNuke Module”

For the first, you will need to open the DotNetNuke website development copy in your Visual Studio. Then simply add a plain file to your eCommerce in DotNetNuke project by making use of a DotNetNuke Dynamic Module template, which comes fully installed with your DotNetNuke Starter Kit package. Open your web.config file to trace the compilation node. Then simply proceed to add a node titled codeSubDirectories under compilation. Add one more item under the codeSubDirectories by using name of your module entered by you in the last step, in the following format: <add directoryName="ModuleName"/>.

Now, go to the Solution Explorer and proceed by locating the DesktopModules directory. Here, you will find a fresh directory that has been created by Dynamic Module template, below your DesktopModules directory. Rename the directory with the same module name used by you in your previous steps. You must next log-in into the DotNetNuke website, opened previously by you in the Visual Studio, by using the facility of a host account provided for the purpose. Under the main menu of this host account, select the Module Definitions option, and then select the Create New Module option. Now, you will need to fill-up this module form by making use of the same module name used by you in the steps followed earlier.

After that is done, click on the Add Control of the form for Create New Module. From the drop-down list, click select on the file that has been added to it by Dynamic Module template. This file represents module name that was specified in your previous steps; only with the extension:.ascx added to it. You now need to open this.ascx file in the Visual Studio. It will display both a code-behind view and design created by the module template. You can add functionality to this code-behind file as deemed suitable to your eCommerce in DotNetNuke. Visual and layout elements may also be added to your design view, if desired. Before making an attempt to create the module, it is advisable to verify DotNetNuke portal installation functionality.

DotNetNuke 7.0 Hosting - :: GZIP Compression to Improve Your DotNetNuke Performance

clock February 11, 2014 07:47 by author Jervis

In this article, I want to describe about IIS SEO Toolkit and the YSlow plugin for FireFox. The SEO Toolkit is invaluable for finding things like broken links, bad markup, etc, while the YSlow plugin analyzes things from a pure performance perspective. I recommend both highly for fine tuning your DotNetNuke websites.

One of the things that YSlow recommends is to compress the files that are sent from the server to the user’s web browser. DotNetNuke provides the option to use GZip compression on the Host Settings page. Turning this feature on is one of the first things I do when I set up a new DotNetNuke installation.

YSlow has the following to say about compression:

“Compression reduces response times by reducing the size of the HTTP response. Gzip is the most popular and effective compression method currently available and generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip.”

That’s great! Unfortunately, not every file on your DotNetNuke site is compressed when you enable that setting at the host level. In fact, in a test against a recent version of DotNetNuke in my local environment, YSlow reports 18 components that should be compressed. When you enable GZip compression in the DotNetNuke Host Settings, that number drops to…..17. This is due to the actual page itself being compressed (which is wonderful, don’t get me wrong). But what are the other 17 components? Static files. Namely JavaScript files (.js) and Cascading Style Sheets (.css).

Now, the fact that there so many external files its an altogether different issue that I will side-step for the purpose of this blog post. Of course I would love it if DNN had 1 dynamically created minified JS file and 1 dynamically created CSS file, period. However, that is currently not the case, and even if it was – wouldn’t you want to gzip those files as well?

Here is the compression report from a recent version of DotNetNuke that has GZip enabled:

You can see that DotNetNuke does pretty darn well with respect to the YSlow configuration, except where it comes to dealing with external files (this report was run with the “Small Site or Blog” ruleset, for those that are curious). So, how can I improve this section of the YSlow report? By letting IIS gzip the static files, of course!

The report above is from a local environment, but this is exactly how behaved prior to implementing some Gzip compression in IIS.

The steps that I used to get IIS to perform GZip compression on all of the static files in my website were as follows:

1. Enable static file compression in IIS
2. Install IIS Resources
3. Add the appropriate file extensions using the IIS Metabase Explorer
4. Restart IIS

Enabling static file compression in IIS

So, first I enabled IIS compression of static files. Note that this is a server-wide solution, and will apply to each of your web sites hosted in IIS. Here are the relevant steps from the MSDN documentation:

To enable server-wide HTTP compression

1. In IIS Manager, expand the local computer, right-click the Web Sites folder, and then click Properties.

2. Click the Service tab, and in the HTTP compression section, select the Compress application files check box to enable dynamic compression.

3. Select the Compress static files check box to compress static files.

4. In the Temporary directory box, type the path to a local directory or click Browse to locate a directory. Once a static file is compressed, it is cached in this temporary directory until it expires, or the content changes. The temporary directory must be on a local drive on an NTFS-formatted partition. The directory cannot be compressed, and should not be shared.

5. Under Maximum temporary directory size, click a folder size option. If you click the Limited to (in megabytes) option and enter a number in the text box next to it, IIS automatically cleans up the temporary directory according to a least recently used rule when the set limit is reached.

6. Click Apply, and then click OK.

After I performed this step, only one random .txt file was compressed, how useful! You can check which files are compressed by looking in the temporary folder that was specified in the above steps.

Add file extensions using the Metabase Explorer

After I installed the resource kit tools, I opened the new Metabase Explorer application from my start menu and performed the following steps:

1. Expanded [Machine Name] –> W3SVC –> Filters –> Compression and selected gzip
2. For the row named “HcFileExtensions” I added “js” and “css” to the “Data” list
3. For the row named “HcScriptFileExtensions” I added “axd” to the “Data” list

Run it and you’ll see the result Proudly Launches IIS 8.5 Hosting

clock February 10, 2014 10:01 by author Ben proudly launches the support of IIS 8.5 on all their newest Windows Server 2012 R2 environment. IIS 8.5 Hosting plan starts from just as low as $1.00/month only.,a leading web hosting provider and ASP.NET specialist, today launched the latest update of the Microsoft IIS technology. The IIS 8.5,  introduces many new features including several that focus on premium media experiences and business application development for faster loading websites, business services and applications regardless of an organisations requirements.

IIS 8.5 will be released with the Windows Server 2012 R2 product. With IIS 8.5, the IIS team continued its focus on scalability and manageability improvements.  IIS 8.5 adds sophisticated features like Dynamic Website Activation, Enhanced Logging and Logging to Event Tracing for Windows in IIS .8.5.

Another wonderful feature of IIS 8.5  is Suspended AppPools. This new feature allows applications hosted on IIS 8.5 to be suspended instead of being terminated, so when the site is shutdown because of the idle timeout, instead of completely killing the worker process, all the state is saved into disk.

“Our customers have been asking us about IIS 8.5 and we are happy to deliver a hosting platform that supports all the latest in the Microsoft Web Stack. With the launched of IIS 8.5 hosting services, we hope that developers and our existing clients can try this new features.” said Dean Thomas, Manager at

Where to look for the best IIS 8.5 hosting service? How to know more about the different types of hosting services? Read more about it on

As a leading hosting provider, offers a comprehensive range of services including domain name registrations, servers, online backup solutions and dedicated web hosting. is well placed to deliver a high quality service.

About is a hosting company that best support in Windows and ASP.NET-based hosting. Services include shared hosting, reseller hosting, and sharepoint hosting, with specialty in ASP.NET, SQL Server, and architecting highly scalable solutions. As a leading small to mid-sized business web hosting provider, strive to offer the most technologically advanced hosting solutions available to all customers across the world. Security, reliability, and performance are at the core of hosting operations to ensure each site and/or application hosted is highly secured and performs at optimum level.

DotNetNuke Hosting - :: How to Optimize Your DNN Installation for Speed and Efficiency

clock February 7, 2014 07:58 by author Jervis

Review some of the default DotNetNuke configurable settings, most of which have been configured for general ease of use. This article will show you how to modify some of these settings ito improve the overall performance of your DotNetNuke installation.

DotNetNuke is a large and flexible web platform and as such has many configurable settings. Most of these settings have been configured for general ease of use, so it is recommended that we review and modify some of these settings if we wish to improve the overall performance of a DotNetNuke installation.

1) Host Settings Configuration

Configuration - Check For Upgrades
When this option is enabled, your website will communicate with “DNN Corp” to check for upgrades. An upgrade check will be performed every time you view the module definitions page or if you view a page with the DNN control bar embedded.

We should turn this option off to reduce overhead and remove the annoying nag images.

Appearance - Show Copyright Credits
This feature injects the DNN copyrights into the page, this just adds more page weight and is not required.

We should turn this option off to reduce page overhead.

1.2) Request Filter Settings

DotNetNuke introduced the request filter feature starting with DotNetNuke 4.5.3, this feature enables you to setup request filters to block or redirect users.

If you do not specifically need this feature, then we recommend that you turn this option off.

1.3) Performance Settings

The default DotNetNuke performance settings are ok for testing environments but production environments will require these settings to be modified. The following sub sections will outline recommendations for the configuration of these items.

Page State Persistence
This setting determines whether the page’s view state is stored in the page or server memory. Although changing this option to “Memory” could reduce the overall size of the request sent to the user, in most cases it causes other problems and I personally recommend NEVER changing this value to anything other than “Page”.

Module Cache Provider
The module caching provider setting configures how DotNetNuke will store the output cache of its module objects. The proper configuration of this setting is dependent on the specific environment that the website will be hosted in. Shared Hosting and Dedicated hosting environments will typically see better results using “Memory” caching. In Cloud computing environments, disk based caching makes sense as website content is stored on a SAN or similar device with very good write speeds, and memory availability is limited.

Cache Setting
This performance setting is used to control how much of the underlying data is cached by DotNetNuke.
We recommend setting this option to “Heavy”.

Authenticated Cacheability
This setting is used to define the cacheability of content for authenticated users, this can be used to optimize what can and cannot be cached by downstream routers and machines when working with authenticated users. For more information on the values in this section please consult MSDN

I recommend that this setting is left at the default value.

Compression Setting
Enabling gzip compression is an easy way to reduce the size of the site payload and get a nice boost in performance. It is possible to disable the DotNetNuke compression and use IIS native compression, however, we have experienced issues with some third party modules and IIS level compression. Therefore it is recommended that we use the DNN functionality unless there is a specific need to compress at the IIS level.

Use Whitespace Filter
This setting will strip whitespace from your generated page content following the Regular Expression specified in the Whitespace Filter option under "compression settings". This option is NOT needed if you are using a compression method. If you are not using a compression method and still would like to see a reduction in page size you can use this option which will slim down the HTML size of your pages.

Output Cache Provider (DNN Prol Only)
This provider is used to cache the entire content of a generated page allowing for zero database lookups and page generation activities to be skipped for un-changed content. This option is not available in the community edition of DotNetNuke.

1.4) Other Settings

Enable Users Online
The Users Online feature allows DotNetNuke to show you which users are currently online. This process adds a fair amount of overhead and it is recommended that you do NOT have users online enabled.

Site Log History
The Site Log History setting controls the data retention policy used by the DotNetNuke Site Log.
We recommend that the Site Log History setting be set to “0” days which will disable all site log functionality.

Scheduler Mode
This setting controls how DotNetNuke scheduled tasks are triggered. The default configuration of “Request Method” requires that on page requests a check is performed to trigger any tasks. This mode introduces additional request overhead and can delay end-user experiences. We recommend setting this configuration option to “Timer Method”.

Enable Event Log Buffer
DotNetNuke writes all kinds of log entries to the event log, user login, page changes, etc. Enabling the event log buffer allows DotNetNuke to queue these log items to cache, thus reducing the number of database writes. Therefore it is our recommendation that this setting be enabled on all installations.

Auto Sync File System
This configuration option enables/disables the automatic file synchronization functionality. We recommend disabling this functionality as it is only needed if files are added to the portal via FTP on a regular basis.

2) Admin Settings

On DNN 5 portals, un-select “Enable Skin Widgets” if they are not being used. This will prevent additional page resources from being injected, and increasing the size of the page.

3) DotNetNuke Scheduler

This is another DotNetNuke sub-system that is worth configuring to ensure the website is optimized
for performance. The DotNetNuke task scheduler provides vital functionality, however if the tasks are
scheduled to run too frequently they will have an adverse impact on the websites performance.

We recommend the following task scheduler optimizations:

First disable all scheduler tasks that are not required by this website installation.

Configure “DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DotNetNuke” to run every 12/24 hours (or whatever best fits your portal requirements, based upon how much Schedule Log your website generates)

Configure “DotNetNuke.Services.Search.SearchEngineScheduler, DotNetNuke” to run every 12/24 hours and retry after 24/48 hours. (again depending upon what best fits your portal requirements). Note: updating this setting will yield a significant improvement in performance.

4) DotNetNuke Event Log

Anyone who uses DotNetNuke for any period of time will soon discover that the “EventLog” can produce a significant hindrance on performance. It is very important to note that DotNetNuke by default does not clear the entries in “EventLog” table. Over time this table will grow to be very large.

You can enable the “EventLog” buffer feature, to minimize the impact, but I recommend truncating this table on a daily basis. This allows for a 24 hour rolling history for any diagnostics purposes and avoids rapid transaction log growth when deleting records. This can be accomplished a number of ways;

SQL Server Scheduled Job

Manual process

Or using a custom module.

Also disable all logs that are not essential for the website installation, this will reduce the number of database requests your website will need to perform, in particular:

Disable “Application Start” log entries

Disable “Application End” log entries

Disable “Scheduler Started”, “Scheduler Event Started” log entries

5) Authentication Providers

Starting with DotNetNuke 4.7.0 additional authentication provider modules were introduced. Website administrators can configure which authentication provider/s is used to authenticate the users against.

Most DotNetNuke sites will only require the standard DotNetNuke Authentication Provider. However, behind the scenes the website will incur a performance hit when additional authentication providers are enabled, even if they are not being utilized.

This performance hit is typically limited to the login page itself where DotNetNuke polls all enabled providers to see if they must be rendered, but the performance impact can be major.

It is our recommendation that all non-essential authentication providers should be disabled.


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