Quiconque souhaiterai se lancer dans le développement d'extensions et de modules DotNetNuke doit disposer d'un environnement de développement adéquat. Nous aborderons dans cet article les spécificités d'un environnement de développement DotNetNuke.

Pré-requis

• Visual Studio 2008 SP1 installé. 
• IIS déployé et les extensions ASP.Net installées et activées. 
• Le Framework .Net 3.5 SP1 installé.
• SQL 2005/2008 installé (l'usage de la version SQL Express ne sera pas abordée dans cet article)

Choisir une version de DotNetNuke

Il est important de bien choisir la version de DotNetNuke sur laquelle baser vos développements.

Si vous n'avez pas pour objectif de distribuer les modules construits à partir de cet environnement à des tiers, nous vous conseillons de baser vos développements sur la version de DotNetNuke que vous avez en production, car vous ne devriez pas développer à l'aide d'une version plus récente que celle-ci. Il existe bien entendu des chemins de traverse pour contourner cela, mais ce n'est pas le sujet de cet article. DotNetNuke 4.9.4, DotNetNuke 5.4.2 ... Pour connaître la version en production sur votre serveur, rendez-vous sur le menu Hôte > Paramètres. 

Si au contraire vous souhaitez distribuer vos modules à des tiers (comme par exemple, à l'aide de la librairie de fichiers DotNetNuke France), vous devrez considérer la pluralité des versions de DotNetNuke déployées chez vos clients comme objet d'attention particulier. Votre module supportera-t-il des versions de DotNetNuke très anciennes ? Fonctionnera-t-il aussi bien sur Dnn 4 et Dnn 5 ?

L'idéal du développeur se situe bien souvent dans une version cible toujours plus récente, la dernière en date, mais l'idéal business quant à lui tendrait bien vers une compatibilité globale en se basant sur la constatation suivante : un grand nombre d'utilisateurs ne mettent pas à jour leur système ou trop rarement.

Le choix de la version sur laquelle baser les développements sera sûrement ordonnée d'un fondement technique : quelle version basse permet aux fonctions majeures de mon module de fonctionner ? Quelle version introduit la fonctionnalité du noyau dont j'ai absolument besoin pour mon module ? 

Egalement à considérer, le facteur de rétro-compatibilité descendante : les version supérieures doivent rester compatible avec les version inférieures. Cette ligne éditoriale du noyau DotNetNuke est stricte mais parfois difficile à respecter pour les développeurs de la Core Team, et parfois vous référencerez des fonctions du noyau n'existant plus dans les versions hautes.

Dans le même ordre d'idées, compiler votre module pour la version 5.4.1 le rendra à priori compatible avec la version 5.4.2, mais l'inverse est parfois faux. Vous référencerez bien entendu DotNetNuke.dll "sans version spécifique" au sein de Visual Studio.

Choisir un package

La version INSTALL est la plus appropriée au développements d'extensions et de module DotNetNuke. Pourquoi recompiler DotNetNuke quand seul votre module apporte de nouvelles fonctions ? Cela s'applique bien entendu dans la mesure où vous ne souhaitez pas modifier le code source du noyau et conserver les possibilités de mise à jour automatiques. Le téléchargement se fait depuis le projet DotNetNuke sur CodePlex

Installation et configuration

Cette section ne détaille pas l'ensemble des étapes à effectuer pour installer et configurer DotNetNuke, mais vous pouvez vous appuyer sur cet article pour plus de détails.

1. Extraire le contenu du ZIP téléchargé dans le dossier de votre choix. Ce dossier sera ensuite pointé par IIS pour constituer le root du site web. Vous aurez peut-être besoin de cliquer sur le bouton "Débloquer" se situant dans les propriétés du ZIP car certaines versions de Windows bloquent l'exécution de certains fichiers contenus dans le package.

2. Configurer IIS. Tandis que Windows XP ne vous laisse créer qu'un seul site web au sein d'IIS, les version plus récentes vous laissent gérer un nombre illimité de sites et répertoires virtuels, ce qui est bien pratique. Créez un nouveau site et définissez le répertoire root du site web.

Si vous utilisez IIS 5 ou 6, vous devrez vérifier que la version d'ASP.Net cible est bien ASP.Net 2.0.

Si vous utilisez IIS 7, vérifiez que le pool applicatif est bien "Classic", car le compte dynamique sous lequel IIS tente d'exécuter l'application pose certains problèmes.

3. Modifier le fichier hosts. Bien souvent j'utilise une URL locale pour mes développements. Du type http://[NomDuClient]- [NomDuProjet], ce évite d'avoir à se soucier d'adresses IP et de ports locaux complexes, et conserve une certaine organisation. Je créé cette adresse en modifiant le fichier c:\windows\system32\drivers\etc\hosts. Ouvrez ce fichier avec NotePad, et ajoutez une ligne avec votre adresse locale : 127.0.0.1 [NomDuClient]- [NomDuProjet]. Par exemple, si je souhaite utiliser en local l'URL http://monURL.com, j'ajoute à la suite du fichier hosts : 127.0.0.1 monURL.com
Enregistrez le fichier, et relancez votre navigateur web.

4. Définir les droits sur les fichiers. Définir les droits sur les fichiers est bien souvent une source d'erreurs car les notions de sécurités et d'héritage ne sont pas bien saisies par tout le monde. Faites un clic du bouton droit de la souris sur le dossier contenant l'ensemble des fichiers du site (aka : le root du site web) et cliquez sur Propriétés puis sur l'onglet Sécurité.

Si vous n'avez pas cet onglet c'est que vous utilisez Windows XP et que vous devez décocher l'usage du partage de fichiers simplifiés depuis le menu Outils > Options.

Vous devez ajouter les permissions pour l'utilisateur responsable de l'exécution du site web. Le nom de l'utilisateur créé par IIS dépend de la version de IIS. Dans le même ordre d'idées, votre administrateur réseau peut avoir défini un compte spécial pour ce genre de tâches. Voici tout de même les utilisateurs par défaut en fonction de la version de IIS : 

• IIS 5 et IIS 5.1 (Windows 2000, Windows XP) : localmachine\ASPNET
• IIS 6 et IIS 7 (Windows 2003, Windows Vista, Windows 2008) : localmachine\Network Service
• IIS 7.5 (Windows 2008 R2, Windows 7) : IIS AppPool\ ou localmachine\Network Service

5. Créer la base de données. Ouvrez SQL Server Management Studio et créez une nouvelle base de données. Je créée toujours ma base de données en suivant le schème  [NomDuClient]- [NomDuProjet]. Créez ensuite un utilisateur SQL qui aura les droits db_owner et Public access sur la base de données. Souvenez-vous du nom d'utilisateur et du mot de passe, il seront utiles pour la suite. 

6. Accèder à l'assistant d'installation. A partir de ce point, les étapes sont faciles. Appelez l'URL du site (Ex. http://[NomDuClient]- [NomDuProjet] ) et l'assistant d'installation démarre. Choisissez l'installation typique, puis continuez jusqu'à l'affichage de la configuration SQL. Choisissez l'installation sur SQL Server 2005/2008, décochez l'authentification intégrée se saisissez le nom ou l'IP du serveur SQL, ainsi que le nom de l'utilisateur SQL et son mot de passe.

L'adresse du serveur peut être : (local) si vous appelez le serveur local, le nom réseau de la machine suivi du nom de l'instance (Ex. MonServeur/SQL2008) ou bien son adresse IP.

Parce que votre serveur est destiné au développement, nous vous recommandons d'utiliser un préfixe pour les tables du Core. Par exemple, saisissez "dnn_" ou "dev_". Ce dernier correspond au paramètre objectQualifier que vous rencontrerez un peu plus tard au moment du packaging des scripts SQL pour la distribution.
La suite n'est que du déjà vu.

7. Modifier le web.config. Ouvrez le fichier web.config se situant au root du site web, et définissez valeur du noeud ShowMissingKeys à True. Cela aura pour effet d'ajouter [L] après chaque texte issu des fichiers de traductions (RESX), vous permettant de voir d'un coup d'oeil les clefs qui ne pourront pas être traduite par le client une fois le module livré. L'option permettra également d'afficher un message au développeur lorsqu'une ressource de traduction appelée est absente des RESX.

Vous disposez maintenant d'un environnement prêt pour le développement DotNetNuke. Vous pouvez utiliser une template Visual Studio distribuée dans le package DotNetNuke "Starter Kit" pour créer votre premier module.

Cet article est largement inspiré et améliore l'article "My DotNetNuke Module Development Environment" du blog de Chris Hammond. Merci à lui pour cet excellent article qu'il m'a paru bon de traduire.