Vicenç Masanas

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

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

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.

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?

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.

New features on page management

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

DotNetNuke latest 4.4 version contains two new features on the page settings control that helps a lot when maintaining large web sites with subsections where you tend to apply different skins and / or permissions.

On any page, when you go to "Page Settings" you will see a new option below the permissions grid.

This option, as the name explains, will copy the currently selected permissions to all descendents of the current page. Can you imagine a good use for this when trying to set some permission to a set of related pages?

On the same idea, how many times have you had to apply the same skin to a page and all descendants (so to a full section of the web site)?

"Copy design" comes to rescue!

Both options (copy permissions and copy design) will honor the current user permissions, so this will only be applied to pages where the user has edit permissions.

DotNetNuke Trainning in Paris

vmasanas@hotmail.com — Sun, 03 Dec 2006 17:45:00 GMT

Next week, from December 11 to december 15, there's a full week of DNN trainning in Paris. They will cover a lot of interesting items: skinning, the framework, module development, DNN services, security, etc.
I've been invited to give a presentation on the first day and I'm very excited to meet all the people interested in DNN and share our vision and ideas around it.

If you are interested in DNN and want to know a lot more about it this is a great opportunity for you. For more information visit Aricie's web site.

Custom Module Permissions. Enhance your modules!

vmasanas@hotmail.com — Tue, 01 Aug 2006 08:05:00 GMT

There's a "old" feature in DNN that allows module developers to create their own custom permissions for the modules they are creating. This will allow you to create a module and specify more granular permissions than the default VIEW / EDIT options DotNetNuke provides by default.

Yet a very powerfull feature I've seen this option not being much used. Actually very few module use that.
Why? I think the reason is because of a lack of documentation and examples from DNN core modules itself (an exceptional exception is the UDT module, from which I based some of this code). So I thought it would be good idea to provide some explanation on this and a piece of sample code for everybody to use.

What do we want
The overall goal of this exercise is to create some custom permissions for a module so it can have other options than the VIEW / EDIT default permissions. For example, decide which roles will be able to edit a specific item in the module.
The new permissions for the module will appear *automatically* on the permission grid in the module settings page without any extra step on your (the developer) part.

Structure
DotNetNuke provides two tables that support this feature. First there is the Permission table where all permissions are defined

and then we have the ModulePermission table where permission for each module are stored.

Note that this table contains not just module related permissions but all permission types (including folder and tabs). If at any given time DNN supports more granular permissions for these objects you will see them defined here.

On the Modules side note that the default permissions are defined with a code of "SYSTEM_MODULE_DEFINITION".
So the first thing to do when creating custom permissions is decide a unique code for your module. I suggest you use something similar to "MODULE_YOURMODULENAME".
ModuleDefId is a reference to the module that "owns" the permissions and PermissionKey, PermissionName define every permission you want to add.

Setup
A small problem with the current solution is that DNN does not provide any automated way to install new permission definitions when a module is installed. I'm sure we will solve this in a future version.

So we'll have to create some code to handle this, and the best way of doing it is by implementing the core IUpgrade interface. This interface defines a method that will be called everytime a new version of the module is installed, even the first version. So just add this piece of code to your controller class to handle the setup of module permissions:

  162         public string UpgradeModule(string Version)
  163         {
  164             if (Version == "01.00.00")
  165             {
  166                 // Install module permissions
  167                 InitModulePermissions();
  168             }
  169             return Version;
  170         }
  171 
  172         private void InitModulePermissions()
  173         {
  174             PermissionController permCtl = new PermissionController();
  175             ArrayList arr = permCtl.GetPermissionByCodeAndKey(ModuleSecurity.PERMISSIONCODE, "");
  176 
  177             DesktopModuleController desktopMod = new DesktopModuleController();
  178             DesktopModuleInfo desktopInfo = desktopMod.GetDesktopModuleByModuleName("MyModule");
  179             ModuleDefinitionController modDef = new ModuleDefinitionController();
  180             ModuleDefinitionInfo modDefInfo = modDef.GetModuleDefinitionByName(desktopInfo.DesktopModuleID, "MyModule");
  181 
  182             try
  183             {
  184                 PermissionInfo pi = new PermissionInfo();
  185                 pi.ModuleDefID = modDefInfo.ModuleDefID;
  186                 pi.PermissionCode = ModuleSecurity.PERMISSIONCODE;
  187                 pi.PermissionKey = ModuleSecurity.PERMISSION1;
  188                 pi.PermissionName = "A custom permission";
  189                 permCtl.AddPermission(pi);
  190             }
  191             catch
  192             {
  193             }
  194             try
  195             {
  196                 PermissionInfo pi = new PermissionInfo();
  197                 pi.ModuleDefID = modDefInfo.ModuleDefID;
  198                 pi.PermissionCode = ModuleSecurity.PERMISSIONCODE;
  199                 pi.PermissionKey = ModuleSecurity.PERMISSION2;
  200                 pi.PermissionName = "Another custom permission";
  201                 permCtl.AddPermission(pi);
  202             }
  203             catch
  204             {
  205             }
  206         }

Note that this code references a class named ModuleSecurity, more on this in a moment.

At this point, when you enter the module settings page for any module of this kind you will see the custom permissions on the permission grid.

and this is how the permission table data should look now.

Use
At this point we have all the infrastructe ready to start using these permissions on our custom module.
Here is a sample class the encapsulates then common needs.
- it defines the permissions definition constants (used in all access to the data)

   23         // Constants
   24         public const string PERMISSION1 = "PERMISSION1";
   25         public const string PERMISSION2 = "PERMISSION2";
   26         public const string PERMISSIONCODE = "MODULE_MYMODULE";

- the interesting part in is the contructor, where you define a varible / property pair to define all the permissions in a more easy way.

 
   43         public ModuleSecurity(ModuleInfo modInfo)
   44         {
   45             ModulePermissionCollection permCollection;
   46             permCollection = modInfo.ModulePermissions;
   47 
   48             ModulePermissionController permCtl = new ModulePermissionController();
   49 
   50             _permission1 = ModulePermissionController.HasModulePermission(permCollection, PERMISSION1);
   51             _permission2 = ModulePermissionController.HasModulePermission(permCollection, PERMISSION2);
   52         }
 
- and finally define a couple properties to wrap these permissions:
 
   56         public bool CanDoThis
   57         {
   58             get { return _permission1; }
   59         }
   60         public bool CanDoThat
   61         {
   62             get { return _permission2; }
   63         }

Now you can use that class on your module's code and do something like that:

    1 ModuleSecurity ms = new ModuleSecurity(this.ModuleConfiguration);
    2 
    3 if (ms.CanDoThis)
    4 {
    5  // do it
    6  ...
    7 }

Conclusion
You can see that without much effort you can provide a much richer configuration interface to your module configuration using builtin DNN capabilities, and take advantage of the gread security features the framework has right out of the box.

Jason Zander video on .NET versions

vmasanas@hotmail.com — Tue, 01 Aug 2006 08:00:00 GMT

A very interesting video from Jason Zander on the new .NET versions (WinFX to .NET 3.0 move) and how they manage all this. Sure this will help clear some misunderstandings on the subject.