Vicenç Masanas

Everthing you always wanted to know about the DotNetNuke package installer

vmasanas@hotmail.com — Sat, 30 Oct 2010 06:13:00 GMT

Early this week I was at the great OpenForce Europe conference organized by the SDN at The Netherlands.
As always it's been a great conference with lots of great sessions and plenty of opportunities to meet some old DNN friend and made some new ones! Networking (and drinking beers) is as important as good sessions, and we have had both of them!

At my session "DotNetNuke installation manifest file (.dnn) explained!" we took a deep look at all the options provided by DotNetNuke for a installing all kind of Extensions (libraries, modules, providers, skins, ...).

Category: Development

Google Sitemap Provider for DotNetNuke

vmasanas@hotmail.com — Sat, 07 Nov 2009 14:58:00 GMT

At OpenForce Europe I showed how to create a new provider feature for DotNetNuke. In this case it was a provider for creating Sitemaps (see www.sitemap.org) for google search optimization. In DNN 5 we added a few options to better support sitemaps but the implementation was still very simple.

Interesting week ahead: CodeCamp, OF, and more!

vmasanas@hotmail.com — Sat, 10 Oct 2009 07:06:00 GMT

DotNetNuke install wizard translations

vmasanas@hotmail.com — Sat, 09 May 2009 11:19:00 GMT

DotNetNuke event in Alicante - Spain

vmasanas@hotmail.com — Fri, 04 Jul 2008 11:03:00 GMT

(If you don't understand spanish, you'd better don't come, because we'll not have translators . The event will also be available online thanks to Microsoft)

Soluciones Web Empresariales con DotNetNuke

Nos complace invitarle al segundo evento sobre DotNetNuke organizado por la comunidad en españa TodoDNN.es. DotNetNuke es el CMS (Sistema de Gestión de Contenido) líder desarrollado en ASP.NET el cual es de libre distribución y código libre (Open Source). Promocionando este tipo de software disponemos de la colaboración de Microsoft MSDN España entre otras empresas. La asistencia es gratuita y puede registrarse a dicho evento al final de este mensaje.

Fecha: 25 de Julio de 2.008
Lugar: Centro de Negocios de Alicante (Alicante)
Agenda
16:00-16:30 Bienvenida e introducción a DNN
16:30-17:45 Localización en DotNetNuke (Vicenç Masanas)
17:45-18:15 Descanso
18:15-19:30 Plataforma de negocios para ISPs (Francisco Pérez)

Organiza: TodoDNN.es
Colaboradores: MSDN España, Disgrafic ITec, Dotware, 2P Systems, Xepient Solutions y Live Data Security.

Registro Presencial
Registro Webcast

More ...

RAD with DotNetNuke

vmasanas@hotmail.com — Wed, 16 Apr 2008 17:44:00 GMT

Next week I'm presenting DNN as a successfull tool for Web RAD on Madrid and Barcelona thanks to Microsoft Spain. If you're around come by and say hello. It will be an introductiory session on what DNN is but also we'll see some of the new features DNN Cambrian will give us.

More information and registrations: Madrid, Barcelona

More ...

Big sites, big modules, big problems? Easy solution!

vmasanas@hotmail.com — Sat, 26 Jan 2008 09:59:00 GMT

I've been fighthing for long with an issue we have on a quite big installation (75+ portals, 6500+ pages, 11000+ modules).
The issue only manifested when installing some modules and it would cause the application to die because of a timeout, so we were unable to install any new modules.

The problem turned out to be in the way the installer process the .dnn file and how it updates the module information.
Basically it went that way:
- Register the DesktopModules
- Register any ModuleDefintions for the modules
- Register all the ModuleControls for all definitions

So in a medium-large module this could be like 4-5 modules, 10-12 moduledefinitions, and 30-40 controls.
The problem is that in each of these updates the system did a clear on the host cache. So all the information that DNN uses to cache was cleared after each of these updates (so around 50 times). That caused that the same information was read again from the db after each call causing at the end the timeout.

The issue with this problem is that it would only appear in big sites and when installing big modules. This it's like and exponential issue: the bigger the site and the bigger the module the easier you'll get this error.

We changed the code so next version will include the fix for this but in the meantime you can patch your DNN installations by doing this easy fix (this applies to any DNN version up and including 4.8). To solve this issue you'll have to open the DotNetNuke solution in VS.NET and recompile the DotNetNuke.dll:

In PaDnnInstallerBase.vb, look for method:
Protected Overridable Sub RegisterModules(ByVal Folder As PaFolder, ByVal Modules As ArrayList, ByVal Controls As ArrayList)

change the following calls:
objDesktopModules.UpdateDesktopModule(objDesktopModule)
objModuleDefinitons.UpdateModuleDefinition(objModuleDefinition)
ModuleControlController.UpdateModuleControl(objModuleControl)

to:
objDesktopModules.UpdateDesktopModule(objDesktopModule, False)
objModuleDefinitons.UpdateModuleDefinition(objModuleDefinition, False)
ModuleControlController.UpdateModuleControl(objModuleControl, False)

and just before this line, at the end of the method code:
InstallerInfo.Log.EndJob(REGISTER_End)

add
DataCache.ClearHostCache(True)

In DesktopModuleController.vb change:
Public Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo)
DataProvider.Instance().UpdateDesktopModule(objDesktopModule.DesktopModuleID, objDesktopModule.ModuleName, objDesktopModule.FolderName, objDesktopModule.FriendlyName, objDesktopModule.Description, objDesktopModule.Version, objDesktopModule.IsPremium, objDesktopModule.IsAdmin, objDesktopModule.BusinessControllerClass, objDesktopModule.SupportedFeatures, objDesktopModule.CompatibleVersions, objDesktopModule.Dependencies, objDesktopModule.Permissions)
DataCache.ClearHostCache(True)
End Sub

to:
Public Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo)
UpdateDesktopModule(objDesktopModule, True)
End Sub

Friend Sub UpdateDesktopModule(ByVal objDesktopModule As DesktopModuleInfo, ByVal clearCache As Boolean)
DataProvider.Instance().UpdateDesktopModule(objDesktopModule.DesktopModuleID, objDesktopModule.ModuleName, objDesktopModule.FolderName, objDesktopModule.FriendlyName, objDesktopModule.Description, objDesktopModule.Version, objDesktopModule.IsPremium, objDesktopModule.IsAdmin, objDesktopModule.BusinessControllerClass, objDesktopModule.SupportedFeatures, objDesktopModule.CompatibleVersions, objDesktopModule.Dependencies, objDesktopModule.Permissions)
If clearCache Then DataCache.ClearHostCache(True)
End Sub

In ModuleDefinitionController.vb change:
Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo)
DataProvider.Instance().UpdateModuleDefinition(objModuleDefinition.ModuleDefID, objModuleDefinition.FriendlyName, objModuleDefinition.DefaultCacheTime)
DataCache.ClearHostCache(True)
End Sub

to:
Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo)
UpdateModuleDefinition(objModuleDefinition, True)
End Sub

Public Sub UpdateModuleDefinition(ByVal objModuleDefinition As ModuleDefinitionInfo, ByVal clearCache As Boolean)
DataProvider.Instance().UpdateModuleDefinition(objModuleDefinition.ModuleDefID, objModuleDefinition.FriendlyName, objModuleDefinition.DefaultCacheTime)
If clearCache Then DataCache.ClearHostCache(True)
End Sub

And finally in ModuleControlController.vb change:
Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo)
provider.UpdateModuleControl(objModuleControl.ModuleControlID, objModuleControl.ModuleDefID, objModuleControl.ControlKey, objModuleControl.ControlTitle, objModuleControl.ControlSrc, objModuleControl.IconFile, CType(objModuleControl.ControlType, Integer), objModuleControl.ViewOrder, objModuleControl.HelpURL, objModuleControl.SupportsPartialRendering)
DataCache.ClearHostCache(True)
End Sub

to:
Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo)
UpdateModuleControl(objModuleControl, True)
End Sub

Public Shared Sub UpdateModuleControl(ByVal objModuleControl As ModuleControlInfo, ByVal clearCache As Boolean)
provider.UpdateModuleControl(objModuleControl.ModuleControlID, objModuleControl.ModuleDefID, objModuleControl.ControlKey, objModuleControl.ControlTitle, objModuleControl.ControlSrc, objModuleControl.IconFile, CType(objModuleControl.ControlType, Integer), objModuleControl.ViewOrder, objModuleControl.HelpURL, objModuleControl.SupportsPartialRendering)
If clearCache Then DataCache.ClearHostCache(True)
End Sub

now recompile and just copy DotNetNuke.dll to your DNN installation.

As always remember to make a copy of your files before doing any upgrade and try it on a testing site.

Conclusion:
Caching is a very important thing since it can save your application from the most expensive db calls (and in DNN we have quite a few of those).
But it's also very important to understand how it is used and check that your code is working fine in different situations.

More ...

OpenForce material

vmasanas@hotmail.com — Thu, 08 Nov 2007 16:03:41 GMT

I've just posted the material for the presentations I did both in OpenForce Europe and USA. Get them here.

Recommendation for a Book Reader / TabletPC

vmasanas@hotmail.com — Wed, 15 Aug 2007 09:34:49 GMT

I've been thinking lately on getting something like the Sony Book Reader. You know with so many information on the net I'm very used to download documents, manuals, even blogs! and read them offline at night. Since I'm not a top computer geek I'm not very familiar with this kind of hardware. I was thinking also that maybe a simple TabletPC or ultramobile pc would do the job, but I'm not sure.

Has to be something realy slim and portable and easy to read with, something you would take with you to bed ( well, not for that you are thing of...).

The idea is that it should be mainly for reading and other features as a bonus. Any suggestion?

More ...

Installing and upgrading modules in DNN, a developer's view

vmasanas@hotmail.com — Tue, 09 Jan 2007 23:28:00 GMT

There's some misunderstanding on how DotNetNuke Modules are installed and which steps are executed during a module installation or upgrade.
I'll try to cover both scenarios on this post and I hope this helps to get a clearer idea of how this works.

Let's first take a look at what happens when a module is installed:

As you may know all the internal versioning of modules (and even the core itself) is built around the node on the .dnn installer manifest and the sql scripts that are included in the installation zip.

When the module is installed DNN will run all sql scripts with a number lower or equal than the one specified in the node. Finally the version in that node will be saved on the DesktopModules table. This will help the core on future upgrades so it can know what version is currently installed.

First thing to note here: A given xx.xx.xx.SqlDataProvider script will only be run once. So no matter how many times you reinstall the same module, each sql script will only run once. This is great because otherwise you will see lots of errors when (for example) trying to create a table that already exists.
This gives to another point: if you had some trouble with a module (for example you removed a stored procedure accidentally during development), repeating the same process again (without first deinstalling the module) will not produce the same result.
So don't expect that reinstalling the same version that's currently installed will solve that problem. Can solve others, but not problems with the database.

Another thing that happens when you install a module is that it fires the "UpgradeModule" method if the module implements the IUpgradeable interface.

Public Interface IUpgradeable
  Function UpgradeModule(ByVal Version As String) As String
End Interface

In fact this method will be called once after any sql script has been executed and it will be passed the version number of the current script. So you have to code your upgrade logic knowing that this method can be called multiple times. This is usually done testing for the Version parameter on a "select case" statement.
The method call will be routed through the EventQueue system after the web application is restarted. A minor difference with regards to how the sql scripts are executed exists though: even if there's no sql script on the module, this method will be called at least once. This is needed to be sure that at least the upgrade logic is executed, even if no sql script exists. So if you are installing a module whose final version will be 03.03.03, be sure that UpgradeModule will be called at least once with that version number.

Also notice that all UpgradeModule(..) calls will be made after all sql scripts have already run. This is true because they will be fired after the application is restarted and the end of the module installation process.
So again, be sure not to do something "strange" on your upgrade logic, assuming that the database has a special structure. For example query a given stored proc, you know in version 01.01.01 existed, because the code will be executed when all scripts for version 03.03.03 are already installed and maybe that stored proc. doesn't exist anymore.

On first time installations this is more or less all that's involved. Upgrading a module has a couple of differences worth noting.

What happens when a module is upgraded:

Execution of sql scripts is more or less the same: each file with a version number greater than the current version number stored on the DesktopModules table, and less or equal than the number included in the node of the .dnn installer manifest will be run in order.

After each xx.xx.xx.SqlDataProvider script is run, the core will search for a corresponding "xx.xx.xx.txt" file on the upgrade package. This file can contain a list of files you want to remove from older versions of your module. You have to specify a file on any line using the relative path from the root of the DNN installation. For example:
bin\DotNetNuke.Modules.Survey.dll
bin\DotNetNuke.Modules.Survey.SqlDataProvider.dll
DesktopModules\Survey\c.gif

So if this file is 03.03.03.txt, and there's a 03.03.03.SqlDataProvider file, it will be "executed" just after the sqlscript and before the UpgradeModule for this version.
This is also another point where you have to make attention: the delete file will only be processed if there's a related sql script.
Afterwards the application is restarted all the UpgradeModule(...) will be called for each sql script that has been run before. Again, UpgradeModule will be called at least once for the final version (the one in the node) , even if no sql script exists.

I hope this brief explanation helps to understand how DNN processes modules during installation and successive upgrades.

More ...