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? 

WebMatrix is Microsoft’s new suite of technologies designed to make creating websites easier.  There are four major components to the new WebMatrix “Web Stack”

1. IIS Developer Express – a new free lightweight web-server, based on IIS 7, that runs on all versions of Windows and does not require Administrator level permissions
2. SQL Server Compact Edition – a lightweight file based database that is simple to set up and free to download.
3. ASP.NET “Razor” – a new  view-engine option for ASP.NET that can be used to easily embed C# or VB code within an HTML page. This is “bin” deployable and free.
4. WebMatrix Tool – a free lightweight developer IDE that integrates all the components.

Have you ever tried to write Unit Tests for multiple implementations of an Interface or Abstract Base Class.  I encountered this problem over the weekend in a personal project and after some poking around I realized that MbUnit supports this ability using the Factory attribute.

In DotNetNuke we make extensive use of the Provider Pattern, so as we develop tests for the core we will encounter this scenario.  In this post in my irregular series on Testing I describe how you can write a single Test Fixture that elegantly handles the testing of any number of concrete implementations.

Earlier today Scott Guthrie announced a new “Web Stack” called WebMatrix.  WebMatrix is both the name of the complete stack (Web Server, Database and View Engine) as well as the name of the new lightweight development tool that you can use to create, edit and publish websites.

In a previous article in this series of blog posts, I described the different Test Doubles that can be used when unit testing your application.

My favourite type of Test Double is a Mock.  Mocks are usually dynamically created by a mocking framework. Mock objects are preprogrammed with expectations which form a specification of the calls they are expected to receive.

In a previous article in this series of blog posts, I introduced Moq (Mock-you) – the mocking framework we are using in DotNetNuke to generate Mock objects for testing.

In DotNetNuke version 5.3, we introduced the concept of a centralized Content store, together with the ability to apply Taxonomies (categories) to the content.  We have extended this in DNN 5.4 by completing the MetaData API as well as adding Folksonomy (user tags).

In an earlier blog I mentioned that since DotNetNuke 5.3, we have supported MVP (Model View Presenter) style Module Development using the WebForms MVP project as a basis.  In this blog  I will begin to explore how we can use the new DotNetNuke base classes ModulePresenter and ModuleView to build fully testable modules.

There are four components for each MVP Module Control.

1. An Interface which defines the View
2. A Model class which will be passed between the Presenter and the View
3. A Concrete View class (the User Control which renders the content to the Response stream) and
4. A Presenter Class which manages everything

In this new blog series of short posts I will “uncover” little know classes/methods - “gems” - in the DotNetNuke Framework (and any of the 3rd party libraries that we use, such as Telerik or the .NET Framework itself).

In this first post, we look at two new helper modules in the DotNetNuke.Common namespace.  A Visual Basic Module is equivalent to a C# static class (ie a class where all the members are static).

One of the biggest challenges in writing Unit Tests - at least when you write them after you have created the actual code, rather than in a Test Driven Development style, is determining what should be tested.

In my spare time, I often find myself playing with ideas for enhancing the DotNetNuke (DNN) core.  Most of the time I am developing prototypes as a “proof of concept” – i.e. they are not complete, and may never be completed.

One example of this is my recent blog series on developing modules for DNN using ASP.NET MVC.  So far I have demonstrated that the default MVC Application created using the ASP.NET MVC version 1 template can be converted, with little effort, into a DNN module.  In order to accomplish this I had to create a framework that sits on top of the DNN core.

Often, when writing Unit Tests you find yourself writing a batch of quite similar tests that exercise the various test cases for a method.

As I am endeavoring to add Unit Tests to all new code I write, I am learning my way through the MbUnit/Gallio Testing Framework which we have standardized on for all DNN testing.  MbUnit is an awesome testing framework and it has a number of Attributes that you can apply to a Test that allows you to provide different parameters. 

In earlier blogs (Part 1 and Part 2 of this series) I described how I have developed a Framework that allows developers to create DotNetNuke (DNN) modules using the new ASP.NET MVC Framework.  In this blog I will describe the new base class which is used to enable this ability - MvcModuleApplication.

Prior to DotNetNuke 5.0, all module controls had to be ASP.NET User Controls that inherited from PortalModuleBase – a base class in the DotNetNuke Web Application Framework that provided the context necessary for DotNetNuke’s Module Injection logic to load and inject the module control in the page. (Since about DNN 4.4 a module control was not required to be an ascx file – it could be a compiled server control, but it still had to inherit from PortalModuleBase and thus ultimately from UserControl).