Dealing with ‘Could not load type ‘DotNetNuke.Common.Global’’

There are a thousand reasons this dreaded message can appear, but what if it appears on a site that you are 100% sure nobody has tampered with in any way other than uploading files for quite some time?

The problem

The error itself is as follows:

Parser Error

Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not load type 'DotNetNuke.Common.Global'.
Source Error:
Line 1:  <%@ Application Inherits="DotNetNuke.Common.Global" Language="VB" %>
Source File: /global.asax    Line: 1

The context

That was exactly the case I faced today when a client called me and reported the error. The client was absolutely sure that no changes had been performed other than uploading some files, both to the application and the server itself (no upgrades, no apppool changes, no iis configuration changes).  Just to be safe, I checked the dates of the files in the bin folder as well as the date of the global.asax file and all had not been changed during the past few months.

Possible causes

Searching the Web, I was panicked to see that there were at least a few dozen possible causes of this error. For example, there’s a multi-page thread in the DotNetNuke forums dicussing this error. Sadly, most of the cases regarded upgrades to the core platform, recompiling or other stuff that had been changed.

So what else could be wrong? Well, I once more discovered than when something seems inexplicable, it doesn’t always have to be some extremely complicated technical issue.


The client had access to the full site root via an FTP client. Upon trying to upload stuff, the client accidentally moved the App_Data folder inside another folder. That was it!

I moved the App_Data folder back to the root and everything was fine again.

What I learned from this incident: Always look for the simplest possible cause of an error first. Hope it helps some of you out there.



What modules I used to develop www.alunet.com (Part 3 – Indoo Grid)

When it comes to displaying data on a grid, you can either choose to implement your own custom module, utilize a module like Open Web Studio (read about it in Part 2) or, if you really want speed and efficiency, install a copy of Indoo Grid.


This module delivers what it promises: Grids. Fully customizable, sortable and editable, either in-line or via a form. Of course, if you really need advanced form functionality, have a look at Dynamic Forms from Datasprings (read about this module in Part 1).


Every multi-purpose module is powerful in a specific area. Indoo Grid is very powerful in presenting data, and provides acceptable functionality for editing data. It’s ideal, though, for administrative tasks, especially if custom tables are involved. That was the case with alunet.com, so I used it heavily at the site administration pages.



Here you can see how the products administration screen looks like. The links to view and edit pages are constructed fields which lead to a Dynamic Forms page and a public detail page respectively. You can sort columns by clicking on them and you can filter data using the text box and the comboboxes above the grid. The “Category”, “Company” and “Views” columns come from respective joined tables. This is not an SQL view you’re seeing – joins are defined in Indoo Grid’s configuration.


You can instruct Indoo Grid to display records from a table or view, defining things such as searchboxes (you can define separate searchboxes for each column or combine them in a single searchbox, excluding the columns you don’t need to search), records per page selector, initial sorting and sortable columns, editable columns (if you need to edit things) and so on.


You also don’t have to worry about those cryptic referential integrity errors when trying, let’s say, to delete something that is related to another table – you can configure it to display messages that are understandable to the user.



This is the grid for managing categories. Remember, the Categories table is a self-joined table that is presented in the form of a tree inside the web site.


You can also create columns that are lookups in joined tables and even automatically create drop-downs from the values of those columns so that you can filter your grid with them. Additionally, you can create “calculated” fields that may contain one or more column values together with other html markup or scripts you may need (yes, that’s an easy way to include pictures or links to other pages).


One thing that Indoo Grid does that you won’t easily find elsewhere is that it can also handle hierarchical data. In alunet.com’s case, the “categories” table is a self-joined table that contains the entire tree of categories, where each record “knows” the id of its parent record. This was easily managed with Indoo Grid.



Here you see the same grid for Categories management, after navigating to a specific category (castings). What we see now are the children of this category in the tree. You can also see that we have an easy way to add new records right below the grid, that will belong to the “Castings” parent category.


Of coure, you can also use Indoo Grid for your front-end. It’s fully customizable in terms of styling and you can always use it in read-only mode. It’s very fast (authors have a demo with a million records which runs pretty smoothly),and there are some predefined templates and samples on their website, too.


Company website: www.indoolab.com

Buy it from Snowcovered: Click


Click here to read Part 1 (Introduction and Dynamic Forms from Datasprings)

Click here to read Part 2 (Open Web Studio)



Adding paging to the core Announcements module

The Announcements module (at the time of writing this, the latest version was 4.0.3) is a very simple DNN core module that lets you present a list of titles and descriptions leading to files, other pages, external links or nowhere at all. It’s customizable via templates, but it doesn’t include any form of paging. So if you have like hundreds of announcements to publish, you probably have to use another module.


Not any more, since with a little help from a clever JQuery plugin called Pajinate (download from here), you can add paging to your announcements module. Of course, you’ll be loading all items since Pajinate functions on the client side, but it’s better than not having paging at all.


I used the default template that comes with the Announcements module and added what was needed to implement paging on it. Unfortunately, Pajinate does not hide the pager when there’s only one page nor does it hide the First/Previous and Next/Last buttons when we are at the first and last page respectively, so I had to write my own little chunk of Javascript to handle this correctly.


Additionally, I adapted the default header and footer templates to include IDs and other stuff needed for pajinate to work correctly. Those IDs are used in the additional javascript code I wrote.


So here’s the Javascript code. I suggest you put this code on a separate file (I used pajinatehelper.js) and load it AFTER the pajinate javascript file. You will probably need to change the value of the itemsperpage variable (top of script) to your own preference, as well as the literals for the First/Previous/Next/Last buttons that follow.

//Set the number of items per page


var itemsperpage = 10;
$('#paging_container').pajinate( {
item_container_id : '#pagetable', //This must be left as is
items_per_page: itemsperpage,
nav_label_first: 'First',//Change this to whatever you like
nav_label_prev: 'Prev', //Change this to whatever you like
nav_label_next: 'Next', //Change this to whatever you like
nav_label_last: 'Last' //Change this to whatever you like

//Get the total number of items
var total_items = $('#pagetable').children().size()

//Get the number of pages
var numberofpages = Math.ceil(total_items/itemsperpage);

//Since we start at page 1, hide First/Previous buttons

//Decide what to hide when user clicks on a page number.

var currpage = parseInt($(this).attr('longdesc'));
currpage+=1; //longdesc is 0-based but page numbers start at 1.

if (currpage==1) {

else if (currpage==numberofpages) {




//Hide First and Previous links when the user clicks the First link

//Hide Last and Next links when the user clicks on the Last link

//Decide what to hide when the user clicks on the Next or Previous links

var currpage = parseInt($('#paging_container').find('.active_page').attr('longdesc'));
currpage+=1; //longdesc is 0-based but page numbers start at 1.

if (currpage==1) {
else if (currpage==numberofpages) {
else {


//If we have only one page, disable pager completely.


//These are helper functions for hiding / showing First/Last/Next/Previous links

function hideFirstPrev() {

function hideNextLast() {

function showAll() {

function toggleFirstLastNextPrevControls (mode) {

if (mode==1) {

else if (mode==2)

else if (mode==3)


Here’s the code for the Header Template for the Announcements module:

<link rel="stylesheet" type="text/css" href="/portals/0/scripts/pajinate.css"/>
<script type="text/javascript" src="/portals/0/scripts/jquery.pajinate.js">
<script type="text/javascript" src="/portals/0/scripts/pajinatehelper.js"></script>

<div id="paging_container" style="text-align:left;">
<table class="DNN_ANN_DesignTable" cellspacing="0" summary="Announcements Design Table" border="0" style="border-collapse:collapse;"><tr><td>
<div id="pagetable">

Please note that I include the stylesheet (pajinate.css), the js file for Pajinate (jquery.pajinate.js – you can use jquery.pajinate.min.js too) and my own .js file (pajinatehelper.js) from my /portals/0/scripts folder (I actually created that “scripts” folder, since it didn’t exist in the default skin’s folder structure). You, of course, can load them from whatever path you like, or you can even inject them in the page’s HEAD section (see this post for more on that).

Pajinate demands that the items to be paged are enclosed inside an element with a specific id (in our case, “paging_container”). You can see the complete documentation here. Unfortunately, this doesn’t work well with tables, so I used an enclosing DIV with this id. Of cource, in your implementation, you can ditch the TABLE alltogether and just use DIVs. I tried to alter the default template as little as possible.

Pajinate also needs a second element that contains elements to be paged. I used this also, as a div with “pagetable” id. Those two are configurable (see the script)

And here’s the code for the footer:

<div class="page_navigation"></div>

The “page_navigation” div is once again required by pajinate in order to show the pager.

Phew. When you put all the code in place, and ensure that it’s working correctly, the result will be something like this:


The orange pager comes from the default stylesheet that comes with Pajinate. You can, of course, change it at your will. In this example, I used a page size of 2.

CAUTION: Since errors in Javascript can sometimes render your page useless and even disable the edit controls, please take a bookmark of the module edit page URL before you apply changes, so you can always get back to it in case things go wrong.

Have fun and good luck!



What modules I used to develop www.alunet.com (Part 2 - Open Web Studio)

Open Web Studio (or OWS in short) is a FREE (yes, free!) module from R2integrated, formerly known as ListX. (There are paid subscription options too, although I'm not quite sure what is offered). At first glance, it looks like a module where you can define an sql query and then create a template to render results - something like a glorified data repeater. But it's a lot more than that. It supports AJAX, paging, variables, it can "talk" to DNN and retrieve things like the tab id, the module id, the locale etc. it can make decisions and branch execution, you can nest modules and have one call another via AJAX, you can do redirections or change page and module titles, you can cache query results and you can even write to files!


Activity lists, product and company lists, product and company details, as well as the users' control panel are rendered via OWS. Additionally, OWS is used in all security checks (such as checking if the user has the right to edit a specific company or product or if the user can add another product). This is achieved via modules that have no front-end but nevertheless run when the page is requested.






Development in OWS is done via a handy tree-like interface where you define things like variables, If - else sections, sql queries, header-detail-alternate detail-footer sections etc.


The site's first page is a good OWS example. The asynchronous effect you will see when you load the first page is because only the main activities are retrieved when the page loads. Subactivities are then queried and rendered via AJAX, and query results are cached for each subactivity (yes, OWS can do named caching on query results so that you don't have to query your database all the time - you can even use fields from your queries to construct names for the cached elements). This is on purpose, since there is a large number of activities and counting products and companies for each one can take some time.


What's more is that you can then have more control over your caching - when a new company or product is submitted, you can clear only the cache that corresponds to the specific main activity it belongs to - leaving all the other query results cached. (No, I haven't done that yet - that's why it's a bit slow :))


Another example would be the company details page, in the future - the site will soon be supporting "packages", i.e. there will be companies that will register for free and companies that will pay. The "free" companies will have fewer details shown than the paying ones. This is very easy to control via OWS.




In fact, I could use OWS to even create the submission forms - but it would be very hard since I would have to do it all by hand - Dynamic Forms is very easier for this type of task. I created the quick search form on the company and product lists with OWS, though. When submitted, it runs a stored procedure which brings the appropriate results - illegal character escaping, injection protection, even parameter type checking and default values assignment are all built-in and easily customizable.

What's the catch? Well, lack of documentation. You've got to turn a lot of knobs and push a lot of buttons to understand what OWS really can do. Fortunately, there's a great community of OWS fans (me included), and this has solved most of my problems.


OWS Pros:

  • Free!
  • Very few bugs compared to other solutions
  • Integrated RAD development environment including debugger
  • It can talk to any external database (you can define connection strings)
  • Supports calls to webservices or even external DLLs
  • Supports caching, ajax, paging, sorting, decisions, variables
  • Can talk to DNN - actually it can retrieve everything the PortalSettings class offers and some more.
  • Very portable configurations, provides an option to even create your own PA assemblies, meaning that you can create your own modules using OWS.

OWS Cons:

  • VERY poor wiki-style documentation (but lots of examples in the community forums)
  • Internal functions have a syntax that is somewhat hard to read (quotes inside quotes, brackets, curly brackets, parentheses, escaped quotes, you can usually find them all in one line)
  • Developer must be very proficient in SQL and HTML / Javascript in order to achieve good results (actually IMHO, this is not a bad thing)
  • Can be painful to debug in very complex scenarios

Company website: www.r2integrated.com

Module website: www.openwebstudio.com

Snowcovered: Click


Click here to read Part 1 (introduction and Dynamic Forms from Datasprings)


What modules I used to develop www.alunet.com (Part 1 - introduction and Dynamic Forms from Datasprings)

Instead of writing another boring "top 10" list of modules "you must use before you die", I chose to present a site I developed (currently online but in Beta stage). This is a unique opportunity, since I usually don't get permission or don't have enough time to publish details on my work.


The site is www.alunet.com, a global directory related to aluminium companies and products, and has been developed using the following DNN modules:




Dynamic Forms from Datasprings

IndooGrid from IndooLab

Open Web Studio from R2integrated

News Articles from Ventrian

Live Tabs from Mandeeps

Navigation Suite from DNN360.net

SmokeRanch Ad Manager from Smoke Ranch Software


(Please be aware that the design is not mine - the layout and site structure was entirely designed by the client and my job was to implement all the functionality needed).


The site is also heavily using jQuery, Fancybox (a jQuery plugin for displaying images and/or html) as well as ImageGen, an image resizer originally developed for the Umbraco CMS that can function stand-alone in any .NET - based website.


Let's discuss where I used what and why:


Dynamic Forms from Datasprings


Dynamic Forms is being used for almost all end-user data submission tasks. This is a very powerful forms generator for DotNetNuke, which allows you to create data-driven forms, storing data either in the module's internal database schema or in any custom external table structure. I am using custom tables for companies, products and categories so I chose the second approach. You can easily load data to your forms as well as save data to your database via SQL queries or stored procedures. You can populate form fields using SQL, and this is especially useful with lookup data used in combo boxes or checkbox groups.  The module supports various goodies like injecting your own javascript, creating your own validations and launching events on form submission that can send email or write to the database. I used Dynamic Forms for the product and company data submission forms that are displayed to registered users.





Registered users can submit their company data. Each user can submit only one company, which is approved by the site's administrator. Companies must have a main activity and subactivities that fall under their main activity (it's a tree with 3 levels). After initial submission, the user must select a main activity and subactivities. (again, Dynamic Forms is used for the selection forms).


When this process is complete, the company must be approved by the site administrators. Users get an email when this is done. (Of course, administrators also get an email for each submitted company). This is achieved via Dynamic Forms post-submission events.


Afterwards, the user is able to submit up to a specific number of products for the company (currently 10, but it's as easy to change as a record in a database table) and assign each product to one of the subactivities they have defined for their company. Actually, the "main activity" acts only as a grouping category, while subactivities are the actual activities of the company.




When editing the subactivity list, the forms present only subactivities that can be selected depending on the main activity chosen and do not let the user unselect a subactivity he has already assigned products to.





Users have their own "control panel" where they can manage companies, products and activities. This works mainly with Open Web Studio, which we'll examine later on.


Dynamic Forms pros:

  • Very powerful
  • Datastore in own schema or custom database
  • Post-submission events (email, sql, etc.)
  • Field events (when you fill a field - you can hide/show sections depending on value etc.)
  • Great selection of controls - including data-driven comboboxes, listbox/radio groups, rich text editor, image and file upload controls.

Dynamic Forms cons:

  • Bugs arise when you try to push it too far
  • Somewhat expensive - you must make sure that you need it
  • Not very good / easy control on final layout
  • Image and file upload controls have many features (e.g. unique filenames, automatic thumbnail resizing) but need a lot of work to operate correctly.

Company website: www.datasprings.com

DotNetNuke Store: Click


Click here to read Part 2 (Open Web Studio)



Injecting CSS / Javascript on your page, revised

A long time ago, I had posted a method to include Javascript in your .ascx skin’s HEAD section. Things have evolved till then, DNN supports JQuery out of the box, and we need an easy way to inject scripts and css stylesheets in our page, taking care that core stylesheets and jquery are loaded BEFORE our scripts, so they can work correctly. This is especially important with JQuery plugins.
Latest DNN versions include two placeholder controls on the default.aspx page, with Ids CSS and SCRIPTS accordingly. These are the controls that can hold our scripts and stylesheets after all core stuff has been loaded, and we can have code inside our .ascx skins that uses these controls and injects stuff like jquery plugins or custom stylesheets inside our page’s HEAD section.
I’ve written some reusable code to do so, which, in this basic implementation, can be used to control what scripts and stylesheets are loaded per skin. Of course, you can customize it even more to control things even on a tab level.
The code has basically two functions, AddCSS and AddJS (what they do is obvious). You must override the Page_Init function and add your calls to the functions there.
Here’s the code. You can use it inline inside your .ascx page, preferrably right after your last @Register statement. 
<script runat="server">
''' <summary>
''' An enum which holds the various type of elements to be
''' injected in the HEAD section of our page
''' </summary>
''' <remarks></remarks>
Private Enum htmlHeadElementType As Integer
css = 1
javascript = 2
End Enum

''' <summary>
''' Add a CSS element to the HEAD section of our page
''' </summary>
''' <param name="csspath">The path to the CSS file</param>
Private Sub AddCSS(ByVal csspath As String)
AddHTMLHeadElement(csspath, htmlHeadElementType.css)
End Sub

''' <summary>
''' Add a JavaScript element to the HEAD section of our page
''' </summary>
''' <param name="jsPath">The path to the js file</param>
Private Sub AddJS(ByVal jsPath As String)
AddHTMLHeadElement(jsPath, htmlHeadElementType.javascript)
End Sub

''' <summary>
''' This is the actual function.
''' It addds the element to the HEAD section of our page.
''' </summary>
''' <param name="elementPath">The path to the file (css, js etc)</param>
''' <param name="elementType">a htmlHeadElementType corresponding
''' to the type of the element
''' we are adding to the HEAD section.
''' </param>
Private Sub AddHTMLHeadElement( _
ByVal elementPath As String _
, ByVal elementType As htmlHeadElementType)

Dim containerControl As Control

Select Case elementType

Case htmlHeadElementType.css

containerControl = Me.Page.FindControl("CSS")

Case htmlHeadElementType.javascript

containerControl = Me.Page.FindControl("SCRIPTS")

End Select

If Not containerControl Is Nothing Then

'Create our generic html control
Dim oLink As HtmlGenericControl

'Decide on what type of element to add
Select Case elementType

Case htmlHeadElementType.css

oLink = New HtmlGenericControl("link")
oLink.Attributes("rel") = "stylesheet"
oLink.Attributes("type") = "text/css"
oLink.Attributes("href") = elementPath

Case htmlHeadElementType.javascript

oLink = New HtmlGenericControl("script")
oLink.Attributes("language") = "javascript"
oLink.Attributes("type") = "text/javascript"
oLink.Attributes("src") = elementPath

End Select

'Add a script reference to the head section
If Not oLink Is Nothing Then
End If

End If

End Sub

Private Sub Page_Init( _
ByVal sender As System.Object _
, ByVal e As System.EventArgs _
) Handles MyBase.Init

'Add the various files to the HEAD section of our page.
End Sub




Fix: Points not added to core DNN Maps module

The DNN Maps module is very simple and useful, but you may come across a problem: When you add points they are simply not added (and when you go to “data” later you see nothing on the list). This behaviour has been reported for module version 01.00.09.


The fix is very simple and I’m posting it here in order to facilitate anyone who’s been having the same problem:


Go to your DNN root folder and find


Change the return value in the mapWriteData function as follows.



return encodeURIComponent(strvalue)

return strvalue


And points will be added normally.


You may need to clear your browser’s cache in order to get it working.

Source: DNN Support Forums



Datasprings Dynamic Forms and image upload problems - a fix for specific scenarios

This may not interest lots of people, but if you're using the very powerful Datasprings' Dynamic Forms module, you may come across it.


The setup


Historically, there have been quite a few bugs with the image upload field in this module, especially when using in combined with the Preview functionality. I had the following setup:


Dynamic Forms module with more than one image upload field.

Preview ON

Thumbnail ON

Initial SQL rendering/bind ON

More than one image fields


Other attributes for image fields (not that it matters, just describing the full scenario):

Custom image folder

Save filename only

Save system generated unique name


I wanted to setup Dynamic Forms to let a user upload, let's say, four images on the same form. I needed to save those in my own database tables and load them from those tables, so I had initial SQL rendering/bind as well as an sql event to save the images back to my custom database table.


The problem


When you use your own sql query to get data for your form, (at least at versions 03.30 to 03.40) thumbnails do not get loaded the first time the form is loaded. Instead, you see the full-sized image (after all, that's what stored in the database).


If you cause a postback (e.g. by clicking on the "upload new image" link on another image field) then the image url is correctly prefixed with "thumb_" and it is presented in the correct dimensions.


The solution


To overcome this, I just added code to my select query that would put the "_thumb" prefix in place even if it wasn't there, like the following:




, field2

, ...(other fields)

, case

  when ltrim(rtrim(isnull(myfield,''))) =''

  then ''

  else 'thumb_' + myfield

  end as myfield

, ...(other fields)

...(rest of query)


So this would always add the thumb_ prefix to the field "myfield".


This solved the problem with the initial form rendering. The first time a user sees the form, the thumbnails are shown instead of the full images.


The second problem


The first solution caused an additional problem: In the case of a postback, as I mentioned before, DF puts its own "thumb_" prefix in the images that are displayed on image fields! So if you attempt to click on "upload new image" in any fields, all the other fields will now have an image starting with "thumb_thumb_", and, since no filename exists that starts with this prefix, broken images will be all you'll see.


Please note that you'll see this only if you're using two or more image fields on the same form (or use any other postback that triggers this behaviour).


The additional solution


I found no way to circumvent this, since it's by design. So I had to resort to JQuery in order to correct the problem. I added a Custom Javascript (you can do that in the Module Configuration section) like the following one:


$(document).ready(function() {

    $('img[src*="/Portals/0/imageuploadfolder/"]').each(function(i,d) {
                 $(d).attr("src").replace("thumb_thumb_", "thumb_")


What it does is take all images that have an src attribute that contains the path /portals/0/imageuploadfolder (replace this with your path) and changes any double "thumb_" prefixes to a single one.


This dual workaround seems to work good so far. Now I know this is a very special situation (Dynamic Forms with more than one image field and initial sql rendering) but I hope someone benefits from this. Take care.

Related Posts with Thumbnails

Recent Comments

Free DotNetNuke Stuff

Free DotNet Videos

  © Blogger template The Professional Template by Ourblogtemplates.com 2008

Back to TOP