Well the Wiki module is back in motion! The last I talked about the module I reached out to see if I could find someone willing to take over the project, unfortunately that didn’t pan out. So now that I’ve cleaned up a few things I needed to get done I’m back in action on the module. I spent a number of hours last night working on one of the biggest issues, the ability to use special characters in the titles of Wiki entries.

For the DotNetNuke Connections conference last month I provided an advanced DotNetNuke module development course as a pre-conference training session. That training covered details on how to implement some of the newer features in the DotNetNuke platform within custom modules, mainly ContentItem integration and Taxonomy features.

For the course I created a very basic Article module for DotNetNuke, ultimately naming it DNNSimpleArticle. For the course I created both a C# and a VB.NET version of the module. Since that course offering I’ve cleaned things up a bit more in the module and just tonight uploaded it to Codeplex at http://dnnsimplearticle.codeplex.com. Please read the full blog post for details on the module, and a few warnings (this module is not supported, use at your own risk)

n an earlier article in this series on the new WebMatrix suite of technologies from Microsoft, I described how we are supporting the use of Razor scripts in DotNetNuke, by providing a “Razor Host” module. 

Having created this cool new Razor script, how do you go about distributing it? 

This article is cross-posted from my personal blog.

As long-time DotNetNuke users well know, DotNetNuke contains an extensive API that makes the platform extremely powerful and flexible.  Over time the core APIs have continued to expand as new features were added and existing features were enhanced.  One of the core APIs which has been part of DotNetNuke since 4.6 was released three years ago today is the XML Merge API.

The XML Merge API was developed to enable developers to define changes that need to occur to any xml based file within the website.  It is primarily used by the core framework to make updates to web.config but has utility beyond just updating web.config.  Web.config management was a huge problem in early versions of DotNetNuke.  Managing and applying the web.config changes every time you upgraded DotNetNuke was a time-consuming and error-prone process.  The XML Merge API was developed in part to address this need.

When I first created the API, I needed a way to merge dozens of custom URL rewriter rules into the siteurls.config for the AspDotNetStorefront module.  These rules could change with new versions of the ASPDNSF module and so I also needed to support the ability to apply these changes in a version specific manner.  My first version was included as part of the ASPDNSF module, but due to a contractual arrangement, I was able to make this API available in DotNetNuke as well.

In this post we’ll explore how to better expose this functionality and take advantage of it within your DotNetNuke website.

So if you’ve been under a rock lately you might not have heard that the annual DotNetNuke conference is coming up. While in the past it has been branded as OpenForce, this year it is just simply DotNetNuke Connections, to better fit inline with the DevConnections banner.

This years event is once again going to be held in conjunction with DevConnections in Las Vegas Nevada, November 1-4. The conference is at the Mandalay Bay Resort and Casino, a great venue that has been the amazing home to the DotNetNuke conference for the previous three years.

So this is the third and final post in the module development series of blogs I started last week. The first two covered

1. Configuring your development environment
2. Customizing and installing a C# module development template

This post is going to tell you how to utilize an open source project called NAnt to package up your modules quickly and easily, so that they can be installed on various DotNetNuke sites. The C# module development template that I released last week comes with a NAnt BUILD script included, so when you create a project using the template (as we do in blog #2) you are ready to use NAnt to package the module, you must get NAnt configure though, so let’s walk through that process.

So this is the first in a series of promised blog posts that I am long overdue on! These posts are a follow up to a Beginning DotNetNuke Module Development webinar that we provided back on May 17th. If you didn’t attend the webinar you missed out, but you do get to benefit from these blog posts if you want to easily get setup and running with C# module development for DotNetNuke.

This first post will be discussing the development environment that I configure when I am doing DotNetNuke module development, in addition to this post I’ve got a post about a free Visual Studio template that I am releasing on Codeplex that makes setting up your first DNN module very easy. As well as another blog post about using NANT to automate the packaging of your DNN modules so that you can easily deploy them to other environments.