Back in January I made a post here about creating semi-automatic module packages on the fly from within Visual Studio.  The method I showed at that time was a little bit primitive but it worked perfectly.  Recently I have had some time to refine the batch script itself as well as the integration point to the DNN project inside Visual Studio.  My recent changes now allow me to make 2 small changes for each project and builds work as I expect, it also creates a conditional system that can handle file deletions as well as dynamic loading of debug or release .dll files to the package.  This posting will cover this new process in detail..

Recently I have worked with multiple clients that have had "minimum version" issues with DotNetNuke modules.  They have a new module, or a new version of an already installed module and they install it on their site.  Just after installation they find out that the module doesn't work with their version of DNN.  Sometimes this isn't a major issue as long as it is only the module that doesn't work and it was a new module.  However most of the time it isn't the case, usually it happens to existing modules that include lots of data.  Since DotNetNuke doesn't offer a rollback function these types of issues can be critical to users of DNN.  Now the first argument that I always hear on this topic is that "people should be backing up their site before an install/update to anything".  I agree with this to a certain extent, but on the other hand these people expect that we as developers will make using our product a pain free situation.  This is where this article come into play, I'll discuss a few methods where developers, including myself need to step up and provide better quality services to the general DotNetNuke public.  I'll even include a step by step guide that will show developers how to accomplish what needs to be done.

My last article on DotNetNuke administration topics was very popular "DotNetNuke Host Settings Explained", this article is the promised follow up that will provide detailed information on the Performance/Compression settings section of DotNetNuke Host Settings.  I will explain what the values do, and also my personal experience with the settings, please keep in mind that all DNN sites are different and your needs may differ from those listed in the article, if you are unsure of the proper settings for you environment, please don't hesitate to ask for assistance in my forum.

This is my seventh revision DNN Upgrade guide.  This version of the guide includes important updates for working with DNN 4.8.2 and customized SqlDataProvider configurations.  Many portions of this upgrade guide are the same as previous versions, however, there are some new items and many minor changes/clarifications.  This is simply due to the LIMITED changes that have truly occured in the area of DotNetNuke upgrades.  If a newer version of DNN has been released and I do not have a new version of this document, please use this version as there are most likely no breaking changes!

In previous articles on this site I have provided tutorials for installing DotNetNuke to a local machine, however, I typically avoid the topic of installing DotNetNuke to a remote web hosting provider.  I have been asked many times why and the answer is simple; installations to remote hosts are not standardized, depending on the hosting providers environments the steps to install can differ greatly.  However, due to popular demand I have created this tutorial which will provide you the basic overview of how to perform a clean installation of DotNetNuke on a remote web hosting provider.  In the article I will try to point out the most common differences between different hosting providers, I will also be providing specific examples regarding the use of the Plesk control panel which is what my hosting provider (3Essentials) uses.  This article is my third revision updated to add some more clarifying points, be sure to share any feedback in the comments section at the bottom of the article!

Installing DotNetNuke can be somewhat difficult at times, therefore I am writing this article to give you a full step by step guide to installing DotNetNuke on a Windows XP Pro system. The instructions are similar for Windows 2000 but might vary slightly, I have tried to note as many differences as possible. Windows Vista installation is similar but requires a few different steps relating to IIS. for Vista information please view my video tutorial.  This guide is my sixth revision and includes additional steps and information based on feedback from previous users.  Additionally a few new instructions and notes have been provided for users installing on Windows 2003 Server to address a few common "stumbling blocks" that have prevented successful installations.

Finding out how many modules you have installed on a site, and additionally how many times those modules are used is something that you would think is very simple within DotNetNuke.  However, it is a bit more complex than one would hope.  By default DNN does not provide a mechanism for you to perform this kind of research, however, I have a very simple SQL Script that will allow you to see ALL modules and from there the total number of instances (in all portals) and the total number of instances that are deleted (in the recycle bin).  From an administrative perspective this is a key piece of information to know.

Following the high popularity of my previous article about the DNN Scheduler I thought I would follow up with this article explaining DotNetNuke Host settings.  This article will give an overview of each section of the host settings.  Some areas might be highlighted in future articles to provide more detail regarding specific configuration options that are of high importance to site administrators.

A few weeks ago Tom Kraak of Seablick Consulting made a blog post regarding modifications to the core Breadcrumb skin object to prevent the last page in the tree from rendering as a link.  I created two different solutions for him, the first was simply a modification to the core breadcrumb object and was not necessarily the best solution.  THe second solution I provided was the creation of a custom skin object, based on the core, but isolated so that it will not be prone to issue with an upgrade.  This tutorial is the promised "overview" of how to create a skin object.  I will not discuss the techical aspect of the modifications that were made to the breadcrumb, but just a general overview of what you actually have to do to create a new skin object.

Recently I was working on a project for a client of mine where I needed to implement a Captcha within a DotNetNuke module.  Now in the past I have implemented Captchas on standard ASP.NET sites but I had yet to work with them in DotNetNuke.  Now, DotNetNuke does have a built in Captcha control which can be used on login/registration, but there doesn't appear to be much information out there about how to implement it in your own projects.  I wanted to provide a quality solution for my client by matching the standard DNN look and feel so I decided to take a dive into the core code and find out just how you can use the Captcha control in your own module development projects.  This article will first quickly explain how I went about finding this information and then will discuss the very simple steps needed to add a Captcha to your project!

Ever since OpenForce '07 in Las Vegas last year I have found myself answering more questions regarding module development and being asked to provide training to more individuals.  I have decided that I should start creating more tutorials here that explain the module development process, therefore this article will be the first in a hopefully long series of DotNetNuke module development tutorials.  This article will walk you through the process of creating a new DotNetNuke module using the C# WAP Templates that are available from BiteTheBullet.co.uk.

In previous articles on this site I have provided tutorials for installing DotNetNuke to a local machine, however, I have never yet approached the topic of installing DotNetNuke to a remote web hosting provider.  I have been asked many times why and the answer is simple; installations to remote hosts are not really standardized as depending on the hosting providers environments the steps to install can differ greatly.  However, due to popular demand I have created this tutorial which will provide you the basic overview of how to perform a clean installation of DotNetNuke on a remote web hosting provider.  In the article I will try to point out the most common areas of difference between different hosting providers, I will also be providing specific examples regarding the use of the Plesk control panel which is what my hosting provider (3Essentials) uses.  This article is my second revision updated to add some more clarifying points, be sure to share any feedback in the comments section at the bottom of the article!

Installing DotNetNuke can be somewhat difficult at times, therefore I am writing this article to give you a full step by step guide to installing DotNetNuke on a Windows XP Pro system. The instructions are similar for Windows 2000 but might vary slightly, I have tried to note as many differences as possible. Windows Vista installation is similar but requires a few different steps relating to IIS. for Vista information please view my video tutorial.  This guide is my fifth revision and includes additional steps and information based on feedback from previous users. 

Prior to following this instruction guide please ensure that you have downloaded the "install" version of DotNetNuke 4.8.0 from http://www.dotnetnuke.com.  You can save the zip file to your desktop for the time being.  You will also need to have SQL Server Express 2005 installed and correctly configured to allow mixed-mode authentication.  You can use windows authentication only, however, that configuration is NOT discussed in this article. (Other SQL Server versions work, but these instructions might not match 100% if using something other than 2005). You must also be logged into your machine with administrative permissions.

Recently I have been building more DotNetNuke modules than in previous months and I found myself spending a fair amount of time building installation packages to test my modules on my secondary DotNetNuke portal.  After spending more time than I care to admit manually copying these files over, I created a simple command line batch program and added it as a post build event in my project.  This way every time I re-compile my module Visual Studio will automatically create my installation package.  Below I will provide a bit of direction as well as providing a link to download my sample .bat file.

This is my sixth revision DNN Upgrade guide.  This version of the guide includes important updates for working with DNN 4.8.0 and customized SqlDataProvider configurations.  Many portions of this upgrade guide are the same as previous versions, however, there are some new items and many minor changes/clarifications.  This is simply due to the LIMITED changes that have truly occured in the area of DotNetNuke upgrades.  If a newer version of DNN has been released and I do not have a new version of this document, please use this version as there are most likely no breaking changes!

This guide is geared towards performing an upgrade in-place directly to the server.  If you are on a hosted web server you will need to make modifications to the instructions to fit your access to the production environment.  Additionally I STRONGLY suggest attempting to perform an upgrade locally BEFORE you update a production hosted site to check all processes, then use a method to deploy the upgrade in a prompt manner to minimize site downtime.  If there is enough demand I will post a "Upgrading DotNetNuke from 4.x to 4.8.0 (or later) on a Remote Host" guide.