Envoyer à un amiEcrire un article DotNetNuke.com LinkedIn

Un module programmé avec la méthode WSP a la particularité de fonctionner presque comme un site web au sein du site web. Le module n'a en effet pas besoin d'être pré-compilé dans une DLL pour fonctionner. Il se pré-compile "à la volée" dès que votre site web répond à sa première demande.

La méthode WAP quant à elle, également appelée "Projet d'Application Web", compile le code source du module en une ou plusieurs DLL. Le code est caché à toute personne disposant d'un accès direct au root du site web.

Je ne vais pas détailler les raisons pour lesquelles vous voudriez utiliser une méthode plutôt qu'une autre, mais beaucoup de personnes préfèrent la méthode WAP pour l'une des raisons suivantes :

• Cacher le code source
• Protéger l'intégrité du module en empêchant les modifications directes
• Favoriser l'intégration du module dans un dispositif contrôlant le code source
• Contrôler plus facilement l'environnement du développeur
• Déployer des serveurs de test d'une manière plus claire
• Réaliser des cycles de développement au sein d'itérations labellisées plus claires
• Bénéficier d'un temps de chargement moins long lors du premier appel au site ...

Vous l'avez compris : dans le cas où vous souhaitez distribuer vos modules, même dans un univers local et peu étendu, la méthode WAP est bien mieux adaptée, puisque la méthode WSP laisse votre code source accessible et modifiable.

La plupart du temps, partir d'une méthode WSP plutôt que WAP est plus facile au début. Si bien qu'un certain nombre de développeurs commencent systématiquement le développement de leur module suivant la méthode WSP, pour mieux changer plus tard vers la méthode WAP. Cela se justifie par le fait que le développement - et notamment la phase de débogage - peut être certes plus rapide avec la méthode WSP. Cependant, vous serez sans doute forcé de convertir votre module WSP à un module WAP par la suite. (Afin de réaliser cette étape, vous ne pouvez pas utiliser les éditions Express de Visual Studio.)

Voici les étapes qui vous mèneront d'un module WSP à un module WAP

Passer de WSP à WAP

Si vous avez déjà fait ça, vous avez sûrement été confronté au problème où votre solution WAP ne regénère pas les fichiers utiles à Visual Studio pour identifier et instancier les contrôles de votre page/contrôle (.designer).  C'est la raison principale de cet article.

J'admets que j'ai fait cette erreur tellement souvent que je me suis efforcé de trouver un chemin qui va forcer Visual Studio à re-générer les fichiers .designer à chaque fois, et pas seulement lorsqu'il décide de le faire.

Notez qu'il ne faut à aucun moment que vous re-génériez votre solution, sous peine de passer à côté du petit tour de passe-passe qui permettra à Visual Studio de créer les .designer. L'article vous dira quand re-générer.

Pour le moment, ne vous souciez pas de Visual Studio. Fermez le au moins le temps de lire cet article car je dois avouer que la première fois cette méthode peut prendre un certain temps à réaliser. Mais quel gain de temps par la suite ! La première fois, j'ai pu migrer mon module vers WAP en moins de 30 minute. Il faut dire que le projet comptai pas moins de 20 contrôles et 3 projets ...

Créer un nouveau dossier pour le module

Parfois cela n'est pas nécessaire, mais vous pouvez vouloir conserver deux environnements de développement distincts le temps de la migration de WSP à WAP.

Créez un nouveau dossier dans /DesktopModules/ et nommez le comme vous le souhaitez. Par exemple, "Mon module WAP". Ajoutez également un dossier "My project" à l'intérieur de ce nouveau dossier.
Si votre module utilise un DataProvider, créez également sa structure (par exemple "/Mon module WAP/Providers/DataProviders/SqlDataProvider/"). Ajoutez également un dossier "My project" pour votre DataProvider.

Votre arborescence devrait donc ressembler à celle-ci :

Déplacer les fichiers de l'ancien dossier vers le nouveau

Dans presque tous les acas vous aurez besoin de tous les fichiers qui se trouvent dans le dossier du module WSP. Dans la plupart des cas, vous aurez également besoin des fichiers du module WSP se situant dans le dossier App_Code. Sauvegardez vos fichiers d'abord, puis déplacez les fichiers originaux vers le module justement créé. Si vous copiez les fichiers, vous devrez résoudre par la suite des conflits dans les espaces de noms. Libreà vous de conserver deux versions parallèles du module...

Si vous copiez effectivement des fichiers depuis le dossier /App_Code/Nom de votre module/, placez ceux-ci dans un dossier "Entities" plutôt qu'à la racine de votre module. Beaucoup de développeurs placent les classes liées à la base de donnée dans un dossier "Entities", et les controllers et autres classes dans un dossier "Components". Cela permet de conserver un accès facile et rapide au sein des classes qui s'avère très pratique à l'usage, mais qui peut s'avèrer trop simple voir inadapté pour des gros modules avec plusieurs dizaines de contrôles s'appuyant sur des architectures de données complexes.

Si vous utlisez un DataProvider, vous prendrez soin de copier les fichiers associés dans le dossier correspondant précédemment créé. Par exemple, vous devriez placer les fichiers "SqlDataProvider.vb" et les scripts d'installation (de création ou de mise à jour de la base de données).

Copier les fichiers de solution (.sln) et de projet Visual Studio

Pour que votre module WAP fonctionne, vosu aurez besoin d'au moins 1 fichier projet (.vbproj), et dans beaucoup de cas, 1 fichier Solution (.sln). Par exemple, si vous avez un projet DataProvider (un fichier .vbproj ou .csproj qui maintenant devrait être placé dans "/Mon module WAP/Providers/DataProviders/SqlDataProvider/"), vous aurez nécessairement besoin d'un fichier Solution. Pour ma part, je choisis d'avoir toujours un fichier Solution, c'est plus facile pour la suite. Ces fichiers sont très importants, car ils indiquent à Visual Studio comment ouvrir votre module WAP, quels fichiers le composent, quelques préférences de compiltion, et beaucoup d'autres choses. Le fichier serait également utilisé par le moteur d'export de modules de DotNetNuke pour construire le fichier manifeste .dnn, dans le cas où vous souhaiteriez déployer votre module sur d'autres instances d'une manière automatique (Serveur de test, de réception, de livraison, ...). Dans le même ordre d'idées, vous aurez besoin du fichier Assembly.vb pour chaque projet.

La plupart des cas donc, vous aurez deux projets au sein de votre solution : Le projet de module à la racine, et le projet DataProvider. Parfois les classes sont unifiées au sein du même projet, dans d'autres cas les classes liées au DataProvider sont éclatées en plusieurs domaines ... Cela dépend de votre module.

La manière la plus facile de créer ces fichiers est de les récupérer depuis un autre module. Téléchargez simplement le code source d'un module WAP, ouvrez l'archive, puis copiez les fichiers sus-mentionnés dans vos projets respectifs. Ne vus préoccupez pas plus de leurs cas pour le moment, nous y reviendrons plus tard. Le module Core Links est un bon exemple de module WAP qui fournit des fichiers pour une copie de ce genre : le module est simple et évolue en fonction des nouvelles méthodes. Je crois l'avoir déjà dit, mais n'ouliez pas que le fichier projet du module racine se trouve dans le dossier root du module racine, et que le module projet du module SqlDataProvider se trouve dans le root du SqlDataProvider.

Mettre à jour les fichiers Solution (.sln) et Projet (.vbproj)

Les fichiers que vous venez de copier ne seront utiles à votre application qu'àprès les avoir édités et modifiés légérement pour coller à votre module. Vous aurez essentiellement besoin de :

• Mettre à jour les espaces de noms,
• Mettre à jour les chemins de fichiers,
• Mettre à jour les chemins de dossiers.

Ouvrez la Solution avec un éditeur de texte. NotePad ou NotePad++ vont très bien. Remplacez le nom du projet et le nom de fichier du projet par les vôtres. Par exemple, si vous partez des fichiers du module Core Links, modifier ceci

Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "DotNetNuke.Modules.Links", "DotNetNuke.Modules.Links.vbproj", "{C9B9FC2D-2D76-4446-897C-BA9E7B68EB0E}"

par cela

Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "YourCompany.Modules.MonModule", "YourCompany.Modules.ModuleName.vbproj", "{C9B9FC2D-2D76-4446-897C-BA9E7B68EB0E}"

Fermez et enregistrer le fichier, puis editez à leur tour les fichiers projets.

Vous devriez déjà avoir défini un espace de nom dans votre module, faites donc un "Rechercher et Remplacer" pour aller plus vite. Portez une attention toute particulière au noeud "AssemblyName" et "DocumentationFile".

Modifiez ensuite les noms des contrôles pour correspondre aux vôtres. Pas de panique : vous n'avez besoin d'enregistrer que les fichiers comportant un CodeBehind, donc les fichiers d'extension ASCX, ASPX, ASHX et associés.

Ne vous souciez pas des autres types de fichiers, ceux-là peuvent être ajoutés au projet à la souris en quelques clics depuis l'interface de Visual Studio ! Epargnez vous donc quelques possibles erreurs.

Presque à la fin du fichier de projet, vous aurez besoin de modifier les noeuds IISUrl et IISAppRootUrl pour coller à l'emplacement de votre module. Vous n'aurez pas ces noeuds dans le projet SqlDataprovider, et il n'est pas nécessaire de les créer. Si vous les avez, c'est que vous n'avez pas copié le bon fichier projet.

Créer les fichiers .designer.vb vides

Vos UserControls et Pages ont besoin d'un fichier .designer pour que Visual Studio sache à qui se référent les contrôles appelés dans le code source. Cela vous donnera également l'accès à l'IntelliSense... Créez un fichier de classe vide pour chaque contrôle, et nommez le en correlation avec le contrôle auquel il se référe. Par exemple, pour un contrôle nommé View.ascx, vous aurez besoin d'un fichier View.ascx.designer.vb.

Ajoutez ensuite dans chaque fichier le snippet suivant. Le nom de la classe (Ici : "NomDeLaClasse") et l'espace de nom (Ici : "YourCompany.Modules.MonModule") doivent respectivement correspondre au nom de la classe et à l'espace de nom déclarés dans le code source du contrôle référant.

Namespace YourCompany.Modules.MonModule
    Partial Public Class NomDeLaClasse
    End Class
End Namespace

Ouvrir la solution dans Visual Studio

Que les impatients se rassurent, l'heure d'ouvrir la solution est enfin arrivée. Ne compilez cependant pas le module avant que l'article vous le dise !

Si vous obtenez une erreur à propos de IIS, c'est que vous vous êtes trompés d'URL et de chemin dans vos fichiers de projet. Fermez Visual Studio et corrigez les chemins.

Lorsque vous ouvrez la solution, il se peut que Visual Studio vous demande si vous souhaitez mettre à jour la solution pour une nouvelle version du Framework .Net. Tant que ce n'est pas pour la version 4.0 du Framework .Net, faites-le, aucun risque de planter votre migration ici.

Vous aurez probablement quelques erreurs ; corrigez les erreurs qui se trouvent dans votre code mais laissez les erreurs de markup de côté pour le moment.

Fermez votre Solution, puis ré-ouvrez la.

Mettre à jour le code des User Controls

Cette étape est des plus simples : au début de chacun de vos contrôles se trouve une directive qu'il faut changer.

Au sein de Visual Studio, remplacez à l'échelle de la solution le terme "CodeFile=" par "CodeBehind=". Cela devrait transformer une directive de ce genre ...

<%@ Control Language="vb" Inherits="YourCompany.Modules.MonModule.View" CodeFile=”View.ascx.vb" AutoEventWireup="false" Explicit="True" %>

... en celle-ci :

<%@ Control Language="vb" Inherits="YourCompany.Modules.MonModule.View" CodeBehind=”View.ascx.vb" AutoEventWireup="false" Explicit="True" %>

Résoudre toutes les erreurs

Finalement, résolvez toutes les erreurs restante dans votre projet. Cela inclut toutes les erreurs de markup, de CodeBehind, et de fichiers de classe. Quelques erreurs courantes que vous rencontrerez :

• Erreurs dans les espaces de noms,
• Références de projets / de DLL au sein des projets,
• Supprimer tout projet / DLL non nécessaire,
• Import d'espaces de noms,
• Suppression de dépendances inter-modules.

Cette étape demeure des plus importantes, car les fichiers .designer ne seront pas générés tant qu'une erreur persistera. Assurez-vous de ne pas passer à l'étape suivante avant d'avoir complètement résolu celle-ci.

Actualiser les propriétés du projet

Rendez-vous dans les propriétés du projet afin de mettre à jour les informations d'assemblage.

Générer la solution

Vous pouvez dès à présent générer la solution. Si vous avez réalisé les étapes précédentes, tout devrait se passer sans encombre ni message d'erreur. Votre compilation devrait être exempte d'erreur et les fichiers .designer devraient avoir été générés. Dans certains cas, les fichiers designers peuvent avoir été générés avant cette étape.

Actualiser le web.config

Parfois cela ne sera pas nécessaire, mais mieux vaut vérifier que le noeud codeSubDirectories du fichier web.config se situant au root du site DotNetNuke ne contient pas de référence à votre module. Si c'est le cas, supprimez la.

Vérifier le dossier Bin

Après avoir généré le module deux étapes plus haut, quelques DLL devraient avoir été créées dans le dossier Bin du root du site web. Si vous ne pouvez pas les localiser, accèder aux propriétés de votre projet pour modifier la propriété "Output build path" de la section "Compile". Recompilez la solution pour placer les DLL de votre projet dans le dossier Bin, et n'oubliez pas de supprimer les DLL placées par erreur ou oubli dans l'arborescence du site.

Affichez le site

Vous devriez pouvoir afficher le site et naviguer avec le menu sans problème. Sur la page où le module se trouve, l'erreur indique très certainement que vous n'avez pas mis à jour le chemin vers les contrôles du module. Pour ce faire, éditez la définition du module depuis le menu Hôte > Extensions ou depuis la table ModuleDefinitions si vous êtes familier avec SQL.

La requête SQL suivante devrait faire ce changement pour vous :

UPDATE [dbo].[ModuleControls]
SET [ControlSrc] = REPLACE([ControlSrc],'/AncienChemin/','/NouveauChemin/')
WHERE [ControlSrc] LIKE '%/AncienChemin/%'

 

Cet article est largement inspiré et améliore l'article "Steps to Convert a WSP DotNetNuke Module to WAP" du blog de Will Strohl. Merci à lui pour cet excellent article qu'il m'a paru bon de traduire.