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)

Related Posts with Thumbnails

Recent Comments

Free DotNetNuke Stuff

Free DotNet Videos

  © Blogger template The Professional Template by Ourblogtemplates.com 2008

Back to TOP