Jun22Written by:Will
6/22/2009
On many DotNetNuke® (DNN) websites you will find an unacceptable number of the following exception:
System.Exception: Error Creating BusinessControllerClass ‘YourModule.Modules.ModuleName.ControllerName’ of module(ModuleName) id=(ModuleID) in tab(TabID) and portal(PortalID) ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
I have put the changing words in bold. Those words will be different for you.
This is almost always the result of the wrong business controller class being specified in the DNN manifest file. In the manifest file, the module developer will specify the business controller class so that DNN knows what Interfaces the module implements (such as: IPortable, and ISearchable). This is very important, because DNN will treat those module a little differently. For example, IPortable allows the module to be moved from portal to portal, very easily and all the while keeping the data from the original instance of the module.
Here is what is found in the manifest file for any given module:
<businesscontrollerclass>YourCompany.Modules.ModuleName.ModuleNameController</businesscontrollerclass>
The problem I am speaking of is usually the result of a typo by the developer. Considering the previous example, you might instead see something like this:
<businesscontrollerclass>YourCompany.Modules.ModuleName.CompanyNameModuleNameController</businesscontrollerclass>
Note that the company name is repeated in the controller name. This is not always the exact typo, but it is something that is easily fixed, regardless to why or how it happened. There are really two ways to get rid of this error:
- Ask for an updated module release to fix this issue
- Run a quick SQL statement to fix the error
The first option is obviously always the preferred method, especially to non-developers. Just tell the module developer/vendor that this error exists, and they should reply with a new release package. It’s very easy to do (provided they are not in the middle of a release cycle).
If you find that you either choose or want to fix this yourself, there is a very simple SQL statement you can run to do so. The first thing you need to do though is determine the actual business controller name and namespace. If this is not your own code, then you will have to use a tool like Visual Studio’s Object Browser. Using our previous examples, here is the SQL needed to fix this problem:
UPDATE [dbo].[DesktopModules]
SET [BusinessControllerClass] = N'YourCompany.Modules.ModuleName.ModuleNameController'
WHERE [BusinessControllerClass] = N'YourCompany.Modules.ModuleName.CompanyNameModuleNameController'
If you are using the DNN SQL module in your Host Menu, you might want to use this version of the previous T-SQL instead:
UPDATE {databaseOwner}{objectQualifier}DesktopModules SET [BusinessControllerClass] = N'YourCompany.Modules.ModuleName.ModuleNameController'
WHERE [BusinessControllerClass] = N'YourCompany.Modules.ModuleName.CompanyNameModuleNameController'
That’s all there is to it… It’s fixed! It is not truly reflected in your DNN site and Event Log though, until the site cache refreshes. If you’re impatient, I have blogged about how to clear the cache in DNN before.