softlogger Latest Articles ::DotNetNuke

4.3 and 3.3 - Upgrade asap - Vulnerability in DotNetNuke could allow access to user profile details

DotNetNuke tutorials, tips & tricks — 2008-01-05T00:00:00

I found this info on the DotNetNuke site, it recommends that you upgrade to the latest point release for 3.3 and 4.3 as a severe security issue has been found - details below

http://dotnetnuke.com/SecurityPolicy/SecurityBulletins/tabid/976/Default.aspx

Published: August 02, 2006

Version: 1.0

Maximum Severity Rating: Critical

Background

For the 3.3.3/4.3.3 releases of DotNetNuke, the membership/roles/provider components were significantly overhauled to allow better granularity of control, and to allow us to make a number of enhancements.

Issue Summary

During the process of rewriting the code to extend the Profile component, an authorization issue was introduced that could allow a user (including anonymous users) to access another users profile.
Due to the seriousness of this issue, further details are not available, users of 3.3.3/4.3.3 are recommended to upgrade to 3.3.4/4.3.4.

Mitigating factors

N/A

Affected DotNetNuke versions

3.3.0, 3.3.1, 3.3.2, 3.3.3, 4.3.0, 4.3.1, 4.3.2 ,4.3.3

Non-Affected Versions:

All other versions

Fix(s) for issue

To fix this problem, you are recommended to update to the latest version of DotNetNuke (3.3.4/4.3.4 at time of writing)

* * * * * * * * * *
DNN Creative Magazine provides DotNetNuke tutorials, articles, reviews all for the DotNetNuke web designer. An issue is released each month. Stats: 145 Videos & 5 MP3 Interviews

DotNetNuke Skinning Toolkit demonstrates all of the skin classes to help you quickly and easily create DotNetNuke skins.

dotnetnuke

DotNetNuke Deployment and Synchronization, Admin Menu Access and Free CSS Skin

DotNetNuke tutorials, tips & tricks — 2007-11-27T00:00:00

In issue 26 of DNN Creative Magazine we explore the development and deployment of a DotNetNuke website, how to synchronise a local installation with a live installation.

This allows you to update the content on the live or local installation and keep both versions in sync without taking the live site offline.

We also demonstrate how to set access to the admin menu so that users can access elements of the menu without the need for full administration privileges.

To finish, we have also included a new pure CSS XHTML skin.

How to synchronize local and live DotNetNuke installations
(Deployment using Red Gate Data Compare software)
(4 videos – 33mins)

How to limit access to the admin menu
(Video - 11min)

Free CSS Skin – Internet Sharing

Issue 12 – CSS Horizontal Menus and Google Adsense

DotNetNuke tutorials, tips & tricks — 2007-11-20T00:00:00

August Issue 12 Released

I am pleased to announce that issue 12 of DNN Creative Magazine has been released.

In this Issue we build on the previous skinning tutorials from issues 5 to 11.

We create horizontal CSS menus and demonstrate step by step creating 3 different horizontal CSS menus using the HouseMenu.

We provide an introduction to Google Adsense as an easy way to monetize your DotNetNuke websites. We demonstrate how you can use the CSS techniques developed over the previous issues to easily incorporate Google Adsense into DotNetNuke websites. This covers blending the ads with the text content of the page and easily placing the ads anywhere you require within the page.

This issue comes complete with 11 videos.

Tutorials:

CSS Menus	How to create Horizontal CSS menus in DotNetNuke using the HouseMenu (7 videos – 65mins) Watch the introduction video (3.8MB)
Google Adsense	Introduction to Google Adsense, how to easily monetize your website Incorporating Google Adsense into DotNetNuke Skins (4 videos – 33mins) Watch the introduction video (4.4MB)

Downloads: To save you time, all of the videos for each issue are available as a single zip download from each issue page.

Download the videos from here:

Issue 12 - CSS Horizontal Menus and Google Adsense
Issue 11 - An in-depth look at Headings and Styling
Issue 10 - The DotNetNuke Skinning Toolkit
Issue 9 - Advanced Content Styling Techniques and CSS
Issue 8 - CSS for Styling and Layout in DotNetNuke
Issue 7 – Developing and enhancing skins
Issues 5 & 6 - Working with skins
Issue 4 – Installation Essentials
Issue 3 - The Really Simple Issue (RSS)
Issue 2 - A Picture Is Worth A Thousand Words
Issue 1 - The World At Your Fingertips

If you have any suggestions for the magazine, or requests, please do not hesitate to contact me, this magazine is for you.

Many thanks,

Lee Sykes
DNN Creative Magazine

View Issue 12

PS. Play PacMan to win a free subscription to DNN Creative Magazine or Tetris to win the File Manager Pro module ($199) from Speerio.

PPS. View the RSS feeds page, keep up to date with the latest information, or display our articles on your website using the DNN Creative Magazine RSS Feeds .

Quick Links:
All Free Content
All Videos
All Interviews
All Articles

Stats: There are now 145 videos on DNN Creative Magazine.

* * * * * * * * * *
DNN Creative Magazine provides DotNetNuke tutorials, articles, reviews all for the DotNetNuke web designer. An issue is released each month. Stats: 145 Videos & 5 MP3 Interviews

DotNetNuke Skinning Toolkit demonstrates all of the skin classes to help you quickly and easily create DotNetNuke skins.

dotnetnuke

Using WiX 3.0 to create a per-user MSI that does not prompt for elevation on Windows Vista

Aaron Stebners WebLog — 2007-11-19T00:00:00

A while back, I posted a summary of some information I learned about how Windows Installer interacts with UAC on Windows Vista. Included in that blog post is a list of steps that must be taken to create a per-user MSI that will not cause a Windows Vista UAC elevation prompt when installing it.

Since then, I've gotten a few questions about exactly how to create an MSI that implements those guidelines. As a result, I decided to create an example MSI to demonstrate these concepts, and also post the setup authoring for this example (created using a recent build of WiX 3.0). Hopefully, this example will help translate the per-user MSI creation guidelines into real-world MSI concepts so that anyone who wants to create their own per-user MSIs will be able to do so relatively easily.

For this example, I chose to create a per-user installer for a Windows Media Center Presentation Layer Web application because this type of application does not require installing any per-machine resources (as long as you do not user the /allusers switch when calling RegisterMceApp as a custom action during setup to register the application with Media Center). However, the general concepts demonstrated in this example will work for other types of per-user applications and not just per-user Media Center applications.

Where to download the example files

You can download the example MSI and setup authoring from the following locations:

Zip file containing all WiX 3.0 setup authoring files, a build batch file that can be used to compile and link the MSI, and a copy of the built MSI - http://astebner.sts.winisp.net/Tools/example_per_user_msi.zip
Source WXS file for the example MSI - http://astebner.sts.winisp.net/Tools/example_per_user_msi_setup.wxs

How to build the example MSI

I included a copy of the built MSI in the sample zip file, but you may also want to modify the source and rebuild the MSI to experiment with some of the settings. To build the MSI using the source files included in this example, you can use the following steps:

Download and install wix3.msi from the latest build of WiX 3.0 at http://wix.sourceforge.net/releases
Download and extract the contents of the example zip file from http://astebner.sts.winisp.net/Tools/example_per_user_msi.zip
Make any desired changes to the sample setup authoring files
Run the file build.bat to compile and link the MSI using the Candle and Light tools included in WiX 3.0

Details about how the example was implemented

Rather than walk through the entire WXS file, I have included comments in the text of the WXS file to explain the purpose for each of the blocks of code in the file. In addition, I want to specifically highlight a few key parts of the setup authoring that are needed in order to build an MSI that will not cause a UAC prompt to appear during installation on Windows Vista. These highlighted items match the requirements for creating an MSI that will not prompt for elevation that are enumerated in this MSDN topic and that I summarized in my previous blog post.

1. Ensure that no actions performed in your MSI require elevation

This means that all files and registry must be created in a per-user location and no custom actions can require administrator privileges. In this example, the directory that the application files are installed to is located under the per-user application data folder. This is defined in the following authoring:

<Directory Id="LocalAppDataFolder" Name="AppData">
<Directory Id="AppRootDirectory" Name="MyApplication"/>
</Directory>

In addition, the component that includes the payload for this example MSI includes a CreateFolder entry, a RemoveFolder entry and a HKEY_CURRENT_USER registry entry that is marked as the key path. This is defined in the following authoring:

<DirectoryRef Id="AppRootDirectory">
    <Component Id="Registration.xml" Guid="f671ee4d-dd0a-4f7f-a4d1-1d181d2f3002" DiskId="1">
        <CreateFolder/>
        <RemoveFolder Id="RemoveAppRootDirectory" On="uninstall" />
        <File Id="Registration.xml" Name="Registration.xml" Source="Registration.xml" Checksum="no" />
        <File Id="Application.png" Name="Application.png" Source="Application.png" Checksum="no" />
        <RegistryKey Root="HKCU" Key="Software\MyCompany\MyApplication" Action="createAndRemoveOnUninstall">
            <RegistryValue Name="Version" Value="[ProductVersion]" Type="string" KeyPath="yes"/>
        </RegistryKey>
    </Component>
</DirectoryRef>

These settings are included in this setup authoring in order to eliminate ICE38 and ICE64 errors when building the MSI.

The example package includes some custom actions to register the application with Media Center, but these custom actions do not require administrative privileges so they will work correctly in a per-user MSI that does not run with elevated privileges.

One other note - the build script included with this example includes a command line argument to suppress errors and warnings related to ICE91 when running Light. This ICE validation test reports warnings if any resources are installed to a per-user location in an MSI. However, in this example, the warning can be safely ignored because the MSI is specifically designed to be per-user, and as we will see in step 2 below, we will also enforce that the MSI can only be installed per-user.

2. Set the ALLUSERS property to an empty string

The following syntax defines the ALLUSERS property but does not assign a value to it so it will be set to blank during installation:

<Property Id="ALLUSERS" Secure="yes"/>

Since this property is a Windows Installer public property, it could be changed by the user when they install the MSI via command line. As an extra precaution, I added a launch condition to this WXS file so that the MSI will not allow you to install if you try to set the ALLUSERS property to something other than blank or 0. This WiX authoring is used to implement this block:

<Condition Message="!(loc.LaunchCondition_AllUsers)">
(NOT ALLUSERS OR ALLUSERS=0)
</Condition>

The error message that appears when this block is invoked is defined in this entry in the WiX localization (WXL) file named Setup-en-us.wxl that is included in the zip file:

<String Id="LaunchCondition_AllUsers">Setting the ALLUSERS property is not allowed because [ProductName] is a per-user application. Setup will now exit.</String>

3. Set bit 3 of the Word Count summary property to 8 to indicate that elevated privileges are not required

This is accomplished in WiX by setting the InstallerPrivileges attribute to "limited" in the Package element. In this example, the Package element looks like the following:

<Package Description="!(loc.Package_Description)"
         Comments="!(loc.Package_Comments)"
         InstallerVersion="200"
         Compressed="yes"
         InstallPrivileges="limited"
/>

The build script included with this example includes a command line argument to suppress errors and warnings related to ICE39 when running Light. This ICE validation test checks the contents of the Summary Information Stream in the MSI. Bit 3 of the Word Count summary property is a part of the Summary Information Stream, and it is a new value introduced in Windows Installer 4.0. Unfortunately, the ICE validation test file (darice.cub) does not currently recognize this new bit, and an MSI that attempts to set it will fail ICE39 tests even though it is authored correctly. Ignoring ICE39 errors is safe in this case because if an MSI that includes it is installed using an older version of Windows Installer that does not recognize it, Windows Installer will ignore it.

A Short Introduction to .Net Satellite Assemblies (aka Resource DLL's, Language DLL's, Localization DLL's, etc)

Gregs Cool [Insert Clever Name] of the Day — 2007-10-24T00:00:00

CodeProject - Satellite Assembly and Implementation Details

"Microsoft released the .NET Framework and common language runtime model, targeting high productivity in software development. Their goal was to create an enriched user experience with easy-to-use products.

Satellite assembly comes into the picture when we develop an application, which is localized on a specific culture. Throughout this article we will explain the use and implementation details of satellite assembly.
...
But in order to talk about localization, we must know about resource files. Resource files are nothing but a key and textual, value collections specific to each language. Therefore, we will have to create a resource file for each language that we plan to support. The .NET Framework classes will retrieve language-specific details from these multiple language resource files based on the chosen language context.
..."

Another localization option for .Net developers...

Pure CSS SEO Layouts for DotNetNuke skins

DotNetNuke tutorials, tips & tricks — 2007-10-24T00:00:00

Issue 25 of DNN Creative Magazine has been released. - This is our second year anniversary!

In this issue we demonstrate how to create advanced pure CSS search engine optimized skin layouts.

These techniques were developed for the new DNN Creative skin. Following the release of the DNN Creative skin we have responded to the requests of our subscribers for tutorials covering how to create these SEO CSS skins.

Continuing the SEO CSS skin layout tutorials we also explore multiple skin layout techniques and reducing CSS code through the skinname.css file.

These are advanced and flexible techniques for improving your pure CSS skins.

This issue comes complete with 8 videos.

Pure CSS SEO Layouts for DotNetNuke skins
(7 videos – 64mins)

Multiple skin layouts using skinname.CSS
(1 video – 8mins)

PowerShell for DotNetNuke

The Accidental Geek - Joe Brinkman — 2007-10-14T00:00:00

For the past couple of months I have been playing with PowerShell and it has been a real pleasure to dig-in and get my hands dirty in a command-line interface again. Not since my early days with the Amiga and ARexx have I enjoyed learning about a new CLI and an associated scripting language. The PowerShell team has done a great job of bringing windows scripting and the CLI into the 21st century. Not only has Microsoft been putting in a lot of effort into PowerShell, but you are also seeing an explosion of third-parties who have also jumped onboard to push the new language and hosting environment. Companies like Sapien, Quest, /n Software, and ShellTools are creating great tools and sponsoring community sites like PowerShellCommunity.org.

With all of this excitement and passion in the PowerShell community, how could I not look to see how I could use PowerShell with DotNetNuke. Thus was born my session idea: PowerShell for DotNetNuke which I will be presenting in Las Vegas at OpenForce '07. During my session I will be showing how you can use PowerShell to enhance managing DotNetNuke, both for installing new sites and for sites that are already up and running.

One of the early ideas I had was that I might even be able to create a DotNetNuke module that would let a user execute PowerShell commands and scripts on the server. Since DotNetNuke allows you to lock down access to any module it is fairly secure. The initial code for this module is based off earlier examples by Scott Hanselman and Dominick Baier. Here is a sample video of my work so far.

I still have some enhancements that I will be making before the conference, but you can download the latest code here.

Posh4DNN Module

Technorati Tags: DotNetNuke, PowerShell, OpenForce '07

5 Free CSS XHTML Compliant DotNetNuke Skins

DotNetNuke tutorials, tips & tricks — 2007-09-13T00:00:00

We have now completed the changeover to the new pure CSS skin for DNN Creative, so for issue 23 we have released 5 free pure CSS XHTML compliant skins for DotNetNuke.

These skins are open source html templates which we have converted to DotNetNuke skins.

Viewing the code from a variety of designers helps to improve your CSS skills and learn multiple techniques for manipulating the layouts and styling of CSS skins....

Skins:

Andreas 01

Andreas 09

Summer Breeze

FreeStyle

Curiously Green

View all skins live

Hope you find them useful.

Page Templates and Page Management

DotNetNuke tutorials, tips & tricks — 2007-09-13T00:00:00

Issue 24 of DNN Creative Magazine has been release.

In this issue we demonstrate how to work with and create your own page templates. We have discovered an easy technique for creating page templates so that you do not require any programming skills to create complex templates.

Page templates are a powerful time saving tool. If you have certain modules that you regularly need to add to a page, you can do this automatically with a page template. If you have content in a Text / HTML module that you always use as a starting point, you can have default content added to a module through a page template.

Following page templates we demonstrate the new page management functions in the latest versions of DotNetNuke. This covers username permissions and various page copying functions.

How to create Page Templates in DotNetNuke
(4 videos – 32mins)

Page Management – New Functions DotNetNuke v4.5.x
(2 videos – 19mins)

Issue 24 – Page Templates and Page Management

DNN 4.5.3 Redirect for ReturnURL Issue

Venexus DotNetNuke Blog — 2007-06-05T00:00:00

We have installed and upgraded quite a few sites to the latest DNN version, 4.5.3, that came out last week and most went seamlessly. However, we have found one issue that has raised it's ugly head quite a few times. After upgrading, if you clicked on "Register" you would be redirected to an admin skinned page with no account fields/content. Looking at the url you can see "/ctl/returnurl". Since the site(s) uses a custom page using a 3rd party module for registration for the account info, it is specified in Admin > Site Settings > Advanced Settings > Page Management > User Page.

Here is the error message:

System.Web.HttpException: Could not load type ''. ---> System.ArgumentException: String cannot have zero length. at System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) at System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) --- End of inner exception stack trace --- at System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) at DotNetNuke.Framework.Reflection.CreateType(String TypeName, String CacheKey, Boolean UseCache, Boolean IgnoreErrors)

Luckily we found a post on the DNN Forums concerning the quick fix...

4.5.3 New user registration not working if specific page defined

In the above post someone else was having a similar issue. It looks like there was a bug reported as well:

http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=5746

While there could definitely been a longer or better description of the problem, it was quickly closed with "unable to reproduce in 4.5.3" the next day without any followup. Luckily the thread on the forums gained the interest of other having the issue and vitkoz was kind enough to run it through debugging to find the issue and hence the issue has been reopened in the DNN issue tracker.

Here is his fix:

"In the file admin/skins/user.ascx.vb, line 142 needs to be changed:

FROM THIS:

Response.Redirect(NavigateURL(PortalSettings.UserTabId,"returnurl=" & ReturnUrl), True)

TO THIS:

Response.Redirect(NavigateURL(PortalSettings.UserTabId, "Register", "returnurl=" & ReturnUrl), True)

You can simply go to that file, make that change, and IIS will recompile it on the next run." - vitkoz

Continuous Integration Environment for DotNetNuke Module Development

Venexus DotNetNuke Blog — 2007-04-20T00:00:00

Continuous integration is a software development term describing the process that completely rebuilds and tests applications frequently. We recently implemented a continuous integration environment to “publish” our DotNetNuke modules to our development/staging DotNetNuke sites.

The main advantages of a continuous integration environment are:

Issues are detected and fixed continuously!
Enhancements and new features are published continuously!
You are warned about problematic code before it is published.
Immediate unit testing of all changes.
Constant availability of a "current" build for testing, demos, or releases.
Bragging rights for developers who have the least number of broken builds.
Huge conservation of time when considering the normal administrative process of Build > Package > install in DNN > Test.
Did I mention this is continuous?

How Our CI and DNN Environment Works

Below is a picture to show you the basics of how our continuous integration environment works.

Disclaimer:

If you are running Visual Studio 2005 Web Developer Express, our setup will not work for you. You can stop reading here, or upgrade, unless you are just curious, then read on…
There have been long discussion on Web Site Projects (WSP) versus Web Application Projects (WAP) and this post is not one to argue about which is better, rather than to say this is what we do, and the basics of how it works.
You are free to comment and collaborate with others on this post. Feel free to even argue about WAP versus WEP, or that you may know of a way to integrate CI with DNN and WSP, we really do not care. However, we do not have time to walk you through setting any of this up, so please do not ask…unless you are interested in one of our DNN support packages, then by all means we can help ;-)

Basics of the process:

A developer “commits” the DNN module code to Subversion.
The commit triggers CruiseControl.Net to “build” the DNN module using a “Trigger” for the project.
CruiseControl.Net can be configured to unit test the module before publishing.
An “ExecutableTask” is used with our custom assembly publisher application to send the .DLL file to the DNN website.
A “BuildPublisher” sends the code from the source directory to the DNN site (D:\DNNSites\ClientDevSite\DesktopModules\CustomDNNModule as example).
Results of “build” are visible in the CruiseControl.Net Web Dashboard.

Implementing CI for DNN Development

Development:

We started DotNetnuke 4 development using the WSP methodology for all of our DNN projects. This has been successful for us for quite a while, especially when using EntitySpaces for the Persistence Layer and Business Objects (it's so easy using ES to generate the DAL. You must check this out if you are not using it). However, we found that to make this work we have to use WAP projects. I have a very fast laptop, but using WSP and doing a build of all of DNN to compile a module can be quite time consuming, taking several minutes sometimes. But, building a WAP project is FAST, saving some development time when debugging and testing builds, especially when doing those final little tweaks. One could argue that WSP is better, but for our setup with one to many developers working on a single module, WAP is the best decision. So, it did not take much to twist our arm to changing our methodology. It is unfortunate that in order to use this for our existing clients and projects, we will need to convert our WSP modules to WAP. But, we have started developing all new modules as WAPs and converting WSP modules to WAP is not a difficult task.

To read about the great WSP versus WAP debate, see the following links:

Shaun Walker’s post on WAP

http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/434/Default.aspx

An interesting debate between Michael Washington and Vladan Strigo

http://www.dotnetnuke.com/Projects/ModuleNews/Forums/tabid/953/forumid/111/threadid/91268/threadpage/6/scope/posts/Default.aspx

WAP Methodology

“Web Application Projects provide a companion web project model that can be used as an alternative to the built-in Web Site Project in Visual Studio 2005. This new model is ideal for web site developers who are converting a Visual Studio .Net 2003 web project to Visual Studio 2005. (Released May 8, 2006)” - http://msdn2.microsoft.com/en-us/asp.net/aa336618.aspx

Michael Washington has a great post on creating a DNN WAP Module:

http://www.adefwebserver.com/DotNetNukeHELP/DNN4_WAP/

Once the module is ready for testing on our client development site, we use TortoiseSVN to “commit” code to Subversion (http://tortoisesvn.tigris.org/).

Source Code Version Control:

We use Subversion for our source code repository and version control system (http://subversion.tigris.org/). We have tried Visual SourceSafe and CVS, but have been using Subversion with success for quite some time now. CruiseControl.Net integrates with Subversion easily. It is also nice that there is a plugin for Subversion that allows us to send our comments directly to Gemini (project management/tracking application) when we commit new code.

Continuous Integration Software:

We use CruiseControl.Net, a .Net port of the Java based CruiseControl

Continuous Integration Server using CruiseControl.Net

The CruiseControl.Net Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications for the DNN module, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.

CruiseControl.Net allows for several different types of “Tasks”, such as:

EmailPublisher (for emailing of build details)
ExecutableTask (for kicking off executables, such as our custom assembly publisher)
NAntTask (for unit testing)
NUnitTask (for unit testing)
RSSBuildsPublisher (for generating a RSS feed with details)
VisualStudioTask (for running something in VS)
Etc.

Here is an example ccnet.config:

<cruisecontrol>
<project name="BPLWantList">
    <workingDirectory>D:\cibuilds\ProjectName\ModuleName</workingDirectory>
    <webURL>http://ourCIdomain.com/server/local/project/ModuleName/ViewProjectReport.aspx</webURL>
    <sourcecontrol type="svn">
      <trunkUrl>svn://localhost/ProjectName/ModuleName</trunkUrl>
    </sourcecontrol>
    <triggers>
      <intervalTrigger name="Quarter Hour Build" seconds="900" />
    </triggers>
    <tasks>
  <exec>
      <executable>VenexusAssemblyPublisher.exe</executable>
      <baseDirectory>D:\</baseDirectory>
      <buildArgs>"d:\Source\ProjectName\DesktopModules\ModuleName\obj\Debug" "d:\DevSites\ProjectName\bin"</buildArgs>
  </exec>
    </tasks>
    <publishers>
      <buildpublisher>
        <sourceDir>D:\cibuilds\ProjectName\ModuleName</sourceDir>
        <publishDir>D:\DevSites\ProjectName\DesktopModules\ModuleName</publishDir>
  <useLabelSubDirectory>false</useLabelSubDirectory>
      </buildpublisher>
      <xmllogger />
      <statistics />
    </publishers>
</project>
</cruisecontrol>

CruiseControl.Net Web Dashboard

The CruiseControl.Net Web Dashboard Application is used for reporting a wide range of information about the builds. At one end of the scale it reports summary details of all projects in your organisation and at the other it can give specific metric output for any specific build.

Here is an example of a simple DNN Module being used in our CI environment:

Notice the failed build notification. While we have not setup unit testing, you can see in the left menu in the image, there are quite a few different options.

Conclusion

For long term DotNetNuke module projects, setting up a continuous integration environment will save a tremendous amount of time in the long run. All of the tools to implement CI are free, lowering the total cost of DNN module development. With a little bit of time setting up your environment, you can provide continuous updates to your clients, all while forcing good coding practices among your developers.

Tags within tags regular expression

Venexus DotNetNuke Blog — 2007-03-14T00:00:00

We ran into an issue parsing some HTML for a DNN content migration project we are working on. We needed to find the actual content of the page, without all of the look and feel. Luckily we found a pretty solid case of an opening and closing div tag that wrapped the entire content of the page. At first we had a basic regular expression for finding the div tags like so:

Dim sRegEx As String = "<div align=" & Chr(34) & "center" & Chr(34) & "[\d\D]*?\</div>"

This worked fine until we ran into some code that had div tags withing the div tags. The following shows you what the reg ex returns.

Example:

Some text here

<div> this is between another div</div>

Here is more text that should be in the content we are ripping.

</div>

After some digging, the following regex does the trick:

Dim regexp As Regex = New Regex( _>

"(<[^>]*?div[^>]*?(?:center)[^>]*>)((?:.*?(?:<[ \r\t]*div[^>]*>?.*?(?:<.*?/.*?div.*?>)?)*)*)(<[^>]*?/[^>]*?div[^>]*?>.*</div>)", _>

RegexOptions.IgnoreCase _

Or RegexOptions.Singleline _>

)

DotNetNuke Commercial Module Licensing

Shaun Walker — 2007-01-03T00:00:00

As an open source project, DotNetNuke is available under an enterprise friendly BSD license. Since the license has no usage restrictions, there has never been any requirement for managing license restrictions in the core platform. However, as a web application framework, DotNetNuke has an advanced extensibility model which allows third party features to integrate seamlessly with the base platform. And while some of these third party features are offered under an open source license, there is also a rapidly evolving commercial ecosystem of products being offered under traditional software licensing models.

In simple terms a software license is an agreement where the owner of a piece of software grants permission for others to use the software under very specific conditions. In a commercial model, the license generally needs to be purchased for a fee. Once a license has been acquired, the vendor is then obligated to deliver a version of the software which provides the functionality specified in the license agreement. This is typically done by providing the software on physical media, providing an ability to download the software electronically, or by providing an "activation key" which transforms a limited trial version into a fully working product. Once this process is complete, the challenge for the software vendor is how to enforce the usage restrictions in the license agreement. Most vendors would prefer to rely on a simple "trust" model, where the responsibility for adhering to licensing terms is passed on to the customer. The model requires very little administration; however, it does have the risk of being significantly abused, resulting in lost revenue or even worse implication for the vendor. To mitigate this risk, most vendors generally try to employ some additional techniques for enforcing the conditions in their license.

As part of our ongoing efforts to provide more services for the DotNetNuke ecosystem, we have been gathering feedback and conducting business analysis on how we can assist developers with their commercial licensing needs. The following information represents the set of high level requirements we have gathered on this topic thus far.

Licensing technology needs to integrate seamlessly with the base platform, without extra configuration or environmental constraints. It needs to be reliable and robust. It needs to work in a disconnected manner with no external dependencies which could impose network latency, performance, security, or privacy implications. It needs to work in an Internet as well as an Intranet scenario. It needs to be simple for the developer to integrate with their products and administrate.

Licensing technology needs to be available to individual software developers. It should not require them to bundle their products with other third party products. Brand identity is a very tanglible asset which consumers use to identify quality and value; therefore, developers work hard to build their brand and create recognition and loyalty. Bundling generally leads to brand dilution and other issues based on association.

Licensing technology needs to provide access to customer information. Customer data is an essential business asset which ultimately becomes part of the valuation of any successful software company. It provides the business intelligence necessary to identify trends in your customers and potential deficiencies in your products. It also provides the direct communication which allows you to provide a high level of support, pursue inside sales opportunities, and cultivate relationships and loyalty.

Licensing technology needs to be flexible. Developers require a high level of control so they can adapt their business model to the evolving needs of their customers. A high level of control also provides the ability to automate administrative tasks and deliver real-time solutions. Dependence on a third party can be a significant business risk if not properly mitigated, as it introduces another point of failure which is outside of your immediate control. In addition, developers need to be wary of long term commitments, exclusivity, or other restrictive business tactics which can affect their future opportunities.

In general, DotNetNuke's approach is to provide value added tools and guidance which help developers create solutions to complex problems. At this time, there are a number of areas that we have identified where we can provide assistance to developers. One minor enhancement which is now in scope is to provide unique identifiers at the portal and host level which developers can rely on for generating localized activation keys. In addition, we will include a standard uasability mechanism where customers can enter their activation keys within DotNetNuke, as well as a secure data store and API which developers can use to save and retrieve these keys. In terms of generating keys and validating them within your products, we are in active discussions with a number of highly reputable component vendors who already possess enterprise-grade licensing technology with a long distinguished track record. Our goal is to work with these vendors to create an affordable, robust solution for DotNetNuke developers.

Our current plans are to release these new services in the first part of 2007. We truly want this to be a collaborative effort so we will be working closely with our Benefactor community and Review Program participants. We anticipate that the feedback, suggestions, and beta testing we get from this highly focussed group will ensure an optimal solution for the entire community.

Performance Enhancements

Shaun Walker — 2006-12-05T00:00:00

So in my last blog I talked about how important it is to have a thorough understanding of the Windows Hosting environment before diving into performance optimizations in your web application. Another critical aspect is having a Performance Test Plan as well as a Test Lab where you can simulate load under various scenarios and measure the results. At the beginning of November, Charles Nurse spent one week in Redmond working side by side with some Microsoft perf experts, putting DotNetNuke through its paces in a robust test lab. The various resources were provided by the Microsoft Web Platform & Tools team and Microsoft Patterns & Practices team and we are eternally grateful to Microsoft for their assistance in this area.

The purpose of the performance testing was to establish some baseline expectations by measuring how DotNetNuke reacted under a variety of load scenarios. Since DotNetNuke is primarily used in a shared hosting environment, we focussed on simulating a highly dense server configuration - with many active IIS web sites competing for server resources. We also limited our testing to ASP.NET 2.0 on IIS 6.0, as it is now the predominant platform for Windows hosting. We compared an early version of DotNetNuke 4.0 with the development code for DotNetNuke 4.4.0 to determine if the recent optimizations resulted in performance and/or scalability gains.

Like many of our previous releases, DotNetNuke 4.4.0 has a central theme which in this case is focused on performance improvements. In DotNetNuke 4.4.0, we analyzed every single application layer and service to try and identify bottlenecks. We used a wide variety of tools and processes and gained some very deep technical knowledge on the intricacies of ASP.NET, IIS, and the Windows Hosting environment. It is never easy to produce a comprehensive solution for a complex problem, but after nearly 4 full-time months, we feel that we have finally reached a point where we can confidently deliver results to the community.

Why did it take so long?

An important thing to remember when it comes to performance tuning is more of an art than a science, as an improvement in one area can very easily lead to a degradation in another. For example, the common methodology which developers use to improve the response time of an application is to reduce the number of calls to the database. Typically this is accomplished with caching. However, based on the information in my previous blog post, we know that memory is a gating resource on a web server; therefore, there is an upper limit to the amount of data you can cache before your application's working set ( memory footprint ) becomes too large and effects scalability. Another important thing to remember when it comes to performance is that although a small gain/loss in one area does not seem like a big deal, when you multiple it across hundreds of active sites on a server, it can make a huge difference. This are just a couple of many variables you need to contend with as you work towards optimizing a web application.

So how did we do it?

Code Refactoring

Using the Red-Gate ANTS Profiler, we were able to profile both the code and memory footprint of the application. The ANTS Profiler is an incredible tool for identifying bottlenecks and providing actual metrics of the application working set. And since the tool is relatively easy to configure, it is simple to test the application under a variety of different scenarios. A good example is testing a new web site install versus testing a fully provisioned production web site - as an application can behave much differently depending on the data volume it is supporting ( ie. a new DotNetNuke install has 1 page, 1 user, and 3 roles whereas a site like dotnetnuke.com has 1000+ pages, 360000+ users, and 50+ roles ). Another important aspect of performance testing is that the largest gains are obtained by optimizing your primary code path ( ie. the code execution path which is followed in 90% of your web requests ). ANTS Profiler does a good job of identifying the methods in your primary code path, regardless of where these methods exist within your application architecture. A few of the big offenders were XML Document handling and Serialization and use of reflection in our CBO utility class.

Caching

Steven Smith created a useful custom free tool ( Cache Manager - http://aspalliance.com/cachemanager/ ) which allows you to granularly view the memory footprint for various objects in your environment. This tool ( along with the ANTS Profiler ) was important for identifying and verifying some issues with our caching architecture.

Since DotNetNuke 2.0, we had been using the ASP.NET Cache for storing our commonly used application entities. This allowed us to reduce the number of database hits, resulting in better response time. Unfortunately, the area where caching was initially implemented was in the Begin_Request page event. This made a lot of sense in terms of optimizing the response time in the primary code path, but it ignored the fact that background threads and administrative interfaces could also benefit from the caching of these objects. Another issue with our caching implementation was that we were storing redundant objects in the cache. Typically we were storing both a collection of objects as well as each individual object under unique keys in the cache. As a result our working set was nearly twice as large as it needed to be.

To address these issues, we moved the caching logic from the Begin_Request page event to the business applicaton layer ( domain ). This allowed the caching logic to benefit all data access scenarios. We also changed our caching logic to use a Dictionary collection rather than an ArrayList, allowing us to store the objects in a single collection which still allows us to access individual objects based on their ID. These caching improvements allowed us to improve response time as well as reduce working set.

Assembly Management

As I mentioned in my last blog, all assemblies in the /bin folder are loaded into the AppDomain when it starts up. So when you have optional assemblies which you distribute with your application ( ie. alternate providers, handlers, etc... ) that are not necessary in the 90% use case scenario, this obviously has bad side effects because these optional assemblies contribute to the memory footprint of the application ( and once they are loaded, they are never unloaded - even if they are never referenced ). As usual, there are many ways to deal with this problem - each with their own advantages or disadvantages.

One solution we implemented in DotNetNuke 4.4.0 is a new "light weight" install model. Basically, DotNetNuke will only install a few basic modules by default. The other modules will exist in the /Install/Module folder ( with a different file extension ) and can be optionally installed through the Host / Module Definitions interface. The result is that you only need to install the modules which you need for your site - and the other modules will not unnecessarily contribute to your memory footprint.

Another solution we have investigated is the use of the Relative Search Path in the CLR which allows you to reference assemblies stored outside of the /bin folder. This is accomplished through the node in the section of web.config. The benefit of this technique is that the CLR will granularly load inidividual assemblies when they are referenced by your application ( rather than loading ALL assemblies on app start ). For core framework items such as Providers, HTTP Modules, etc... we have verified that there are performance gains ( we are still investigating the upgrade complications ). For custom modules, it is not so simple and it appears that module developers would need to follow some strict guidelines in order to support this model. We are still investigating this scenario.

One other solution which is often suggested is the use of the Global Assembly Cache ( GAC ). In order to support GAC installs, all of the assemblies in DotNetNuke need to be strongly named and the APTCA bit needs to be set. However, the practical limitations of using the GAC really do not make sense for DotNetNuke. Most Hosters tightly control the components which are installed in the GAC ( since they run in Full Trust ), and would not consider installing an application like DotNetNuke. This is not because DotNetNuke is untrusted, but rather because DotNetNuke is a pluggable application framework which allows third party modules to be installed at runtime. The combination of these factors represent a significant security risk in a shared hosting environment. In addition, the GAC allows for side-by-side installs of different versions of the same assembly. Based on DotNetNuke's agile release schedule, the administration of different release versions in the GAC would extremely challenging to manage effectively. Use of the GAC in a Dedicated server or Intranet environment may be feasible but it would certainly require some due diligence prior to production use.

Database

Using the SQL Server Profiler as well as some custom profiling scripts created by Bert Corderman, we were able to capture database performance metrics for both a clean install scenario as well as a high traffic production scenario ( dotnetnuke.com ). This type of profiling identified the most frequent and slowest database queries. Optimization involved offloading some calls to the cache, tuning the database schema with strategic indexes, and rewriting some stored procedures to make them more efficient.

Compression

One of the things which many of us developers take for granted is the fact that not everyone in the world has broadband Internet access. The infrastructure in some countries has not been upgraded to provide the same data transfer rates which we have come to expect in North America. This results in latency issues where the amount of time to transfer a standard HTML page to a client browser can vary drastically. As a result, reducing the payload ( size ) of each web response becomes a critical aspect to delivering a responsive web experience.

One of the common techniques for reducing payload is to leverage HTTP Compression. HTTP Compression uses an algorithm to compress the response stream and reduce its size. IIS 6.0 has an integrated GZIP compression service but most Hosters do not enable it by default for a couple of reasons. First, compression does have the possibility of increasing CPU usage as the compression algorithm is procesor intensive. Second, compression does not cooperate with certain web application activities such as streaming ( uploading/downloading ) which means that the generic IIS 6.0 compression feature has the potential to break ASP.NET applications ( resulting in support tickets for the Hoster ).

More than 18 months ago we were privileged enough to get support from Ben Lowery in the form of a contribution of his popular HTTP Compression module. Unfortunately, as a seperate DotNetNuke project, this module did not get the attention it deserved from our team. As a result, the HTTP Compression module was never bundled with the standard DotNetNuke distribution, which severely limited its adoption within the DotNetNuke community. In DotNetNuke 4.4.0 we have made the HTTP Compression module a first class citizen and have integrated it directly with the core framework. The module has a couple features specific to DotNetNuke - a whitespace filter using RegExp and a simple configuration file and UI for managing "exclusions" ( URLs which should not be compressed ).

Page State

In the same vein as Compression, all ASP.NET applications use a technique known as ViewState for persisting state across web requests. ViewState is stored within the page payload and has the potential to bloat your response stream, resulting in latency issues in lower bandwidth scenarios. A common technique for dealing with ViewState is to remove it from the page payload and store it on the web server. ASP.NET 2.0 makes this very simple and we have now integrated an alternate Page State persistence mechanism into the core framework.

As you can see, there has been significant focus applied to the theme of Performance in DotNetNuke 4.4.0. I think we all need to recognize Charles Nurse for his incredible effort during this development phase. An initial beta package will be released to Platinum Benefactors at the end of this week for early testing.

And then there was Search...Part II

Venexus DotNetNuke Blog — 2006-11-25T00:00:00

I know it has been over a week since the last post. Sorry to leave you hanging, but sometimes there are just not enough hours in a day. Anyway, without further ado, here is part two…SEAMUS.

At some point earlier this year, DNN Find became a different mission. We decided to build a full blown search engine for DotNetNuke. Not one that would just index a single DNN site, but one that would allow you to index all portals in a DNN installation AND information from external sites. And how would external site indexing best be handled? …via RSS feed aggregation of course.

Seamus is the first of the two modules that make up the Venexus Search Engine. SEAMUS = Search Engine Aggregation Module Utilizing Syndication. On a side note, there is also an obscure Pink Floyd song that not many know from the Meddle album, about an old hound dog by the same name. Our hound dog “fetches” data and stores it to a table that has enabled MS SQL Server full-text indexing. But before I go into the specifics, I think it is important to know about the framework.

We started with traditional DotNetNuke module development…until EntitySpaces was released. I’m an old ASP/VB developer and personally, it took me a bit to get my head wrapped around how ES worked, but once I figured it out, I was hooked. ES saves the day by automagically generating all the CRUD (create, read, update, delete). While very similar to the logic of a BusinessController and InfoObject, ES uses Collections and Entities. But, where I found ES the most useful is the Dynamic Queries you can write directly into the business logic.

For example, in Seamus we need to check the domain to see if it matches one we are already indexing:

            Dim colDomains As New VenexusDomainCollection
            colDomains.Query.Select(colDomains.Query.DomainName, colDomains.Query.DomainID)
            colDomains.Query.Where(colDomains.Query.DomainName.Equal(GetDomainName(sURL)))
            colDomains.Query.Load()
            If colDomains.Count > 0 Then
                     ‘a bunch of removed logic goes here..
            End IF

With the colDomains.Query.Select, we are only returning the data we need rather than all columns. With the colDomains.Query.Where, I eliminated the need to:

Write a stored proc just to retrieve by DomainName
Iterate through the entire table, every row of all domains, just to find the one I am looking for.

I won’t even go into the performance gain of not having to loop through those rows of all columns, nor the time (even though it would be simple) to write a stored proc to pass in DomainName and have it return the DomainID.

Here is an example of adding a record to Seamus for a new feed:

         Dim entFeed As New VenexusSeamus
         entFeed.AddNew()
         entFeed.Url = txtURL.Text
         entFeed.Title = txtTitle.Text
         entFeed.Account = txtAccount.Text
         entFeed.Password = txtPassword.Text
         entFeed.CacheTime = txtCacheTime.Text
         entFeed.FeedTimeOut = txtTimeOut.Text
         entFeed.DateAdded = Now()
         entFeed.DateUpdated = "1/1/1901"
           If chkActive.Checked = True Then
              entFeed.IsActive = True
            Else
                entFeed.IsActive = False
            End If
         entFeed.Save()

Easy enough, eh?

And here is an update of a feed for Seamus:

    Dim entFeed As New VenexusSeamus
    entFeed.LoadByPrimaryKey(hidRSSID.Value)
    entFeed.Url = txtURL.Text
    entFeed.Title = txtTitle.Text
    entFeed.Account = txtAccount.Text
    entFeed .Password = txtPassword.Text
    entFeed.CacheTime = txtCacheTime.Text
    entFeed.FeedTimeOut = txtTimeOut.Text
    entFeed.DateAdded = Now()
    entFeed.DateUpdated = "1/1/1901"
          If chkActive.Checked = True Then
              entFeed.IsActive = True
          Else
                entFeed.IsActive = False
          End If
    entFeed .Save()

And a delete example:

    Dim entFeed As New VenexusSeamus
    entFeed.LoadByPrimaryKey(hidRSSID.Value)
    entFeed.MarkAsDeleted()
    entFeed.Save()

Yeah, it’s that easy. Makes you want to fire up your IDE eh?

Sure, I have used DAL Builder Pro, which was a huge time saver, but EntitySpaces made me to never want to develop any other way. Plus, last I checked, DAL Builder Pro was still only for DNN 3 development. The ease of generating the DAL and the ability to easily REgenerate the DAL if the database schema changes, makes ES the tool of choice for all of our module development. I cannot even begin to count the hours I have previously spent hand coding changes in a DAL due to spec changes. Oh how I wish I had all those hours back!

With the new DNN admin grid templates, it is just ridiculous how much code is generated before having to write the first line. The new template will generate an editable grid of the table(s), with sorting, paging, and search. If you are interested in .Net development (this is not just a DNN tool, it works for all .Net 2.0 development and using C# or VB.Net), you must check it out.

NOTE: Just so you know, we do not have any affiliation or partnership with EntitySpaces, we just think their tool rocks.

So, even though we had much of the initial Seamus development completed, we scrapped it and started development with ES. This will make future modifications and additions so much easier, saving time in the long run.

With that said, here is how Seamus works…

After you install Seamus, you can go into the module settings:

So in this example, the display for Seamus should show the top 10 items last indexed, each with a link to the actual item in the Title and using the “…More” link. A feed icon will also be displayed that provides a link to a RSS feed for the top 10 items.

Here is an example of the display:

Now while the above example does not show any local items (tabs or modules from this site), it does have items indexed from other sites. All of these items were from RSS feeds that were aggregated. As a module editor, you have the ability to manage external feeds (or local feeds if so desired, but we will go into more detail about how Seamus works shortly). But, if there were local items visible, they would only be visible if you have the proper permissions. Seamus checks permissions on any local site at the module and tab level for the display and the RSS feed.

Here is an example of the feeds we are are currently indexing on the Venexus Search Engine:

Here is the interface for adding new feeds:

Now we will get into how Seamus works…

First off, on the first load of Seamus, a dump of data from all modules supporting the IPortable interface (currently limited to DNN Core modules) is performed to ensure that there is data in the index. And every X hours (determined in module settings), the index is checked for new, updated, and deleted pages/modules.

Secondly, any feeds that have been added to Seamus are aggregated 5 at a time, order by last updated. And, while the user is sitting on the page, every 30 seconds that pass, 5 more feeds are aggregated via AJAX. This user interactive aggregating decreases the load on the server, rather than running as a scheduled task like the core DNN Search.

In order to save bandwidth, and to not tick off the owners of the websites you are aggregating data from, Seamus has what I call “smart caching”. Each time a feed is requested, if the information in the feed as not been updated, Seamus will increase the cache time. If the feed has been updated, it will request the same feed sooner than it had previously, decreasing the cache time. Over time, and based on the “average” a feed it updated, Seamus learns when to check again for updates, all while obeying TTLs.

Seamus will also index the current page/tab it is sitting on. Now you may be asking why you would index a page that displays items that have already been indexed. Well, Seamus can be setup to not display the top X items and/nor the RSS feed. Here is an example:

With the above Seamus settings and the module settings to display on all pages and set to not display the container or using an “invisible” container, when a user lands on any page of the site, the page is indexed. You can index your entire site by letting the users "crawl" the website. Also, when the page is updated, the index will be updated. Here is the module settings example:

So, not only does Seamus index all portals in the DNN installation by doing a dump of all modules that support the IPortable interface and individual page indexing based on user interaction, it will also aggregate and index data from other sites. This gives you the ability to create a full blown search engine for your niche. For example, let say you have a website about racing. You could have your entire DNN site indexed, along with aggregation of more racing data from the following sites:

http://www.sportsline.com/partners/feeds/rss/auto_news

http://rss.news.yahoo.com/imgrss/events/sp/042103autoformula

http://rss.cnn.com/rss/si_motorsports.rss

Not only are you able to display a list of the last items indexed in order to keep a page from becoming stagnant, you can also provide a RSS feed for your users, giving them a reason to return to your site. I will save a Seamus and SEO discussion for another time, but here is an example site for a legal search engine.

Speaking of time, I am once again out of it. Part III will be a discussion of the second module, the search form module. Stay tuned...