Comment configurer un environnement de développement DotNetNuke avec le contrôle de source?

Question

Mon équipe est en train de développer une nouvelle application Web DotNetNuke et aimerait savoir ce qui est recommandé pour installer un environnement de développement avec un contrôle de source et des builds automatisés? Nous souhaitons conserver le code source DNN séparé de nos modules personnalisés et du code source des extensions. Le modèle DotNetNuke Compiled Module pour Visual Studio nous demande de stocker le code source dans le répertoire DesktopModules du code source DNN et de le sortir dans le répertoire bin du code source DNN. Est-ce la structure recommandée? Je préfère conserver les fichiers dans des emplacements différents, mais il devient alors plus difficile d'exécuter et de déboguer localement car cela nécessiterait une installation du module pour chaque changement. De même, comment un build automatisé devrait-il déployer des changements?

Comment les autres l'ont-ils configuré? Y a-t-il une meilleure pratique recommandée?

Answer 1

Nous tenons généralement à conserver le code du module dans un dossier sous DesktopModules et à créer le répertoire bin du site Web.

Dans le contrôle de la source, nous ne faisons que mapper les modules individuels, plutôt que l'ensemble du site Web. En fonction de ce sur quoi nous travaillons, un module peut être un projet complet dans le contrôle de la source, ou nous pouvons avoir plusieurs modules associés dans le même projet, vivant côte à côte.

Le déploiement automatique des modifications est quelque peu difficile dans DNN. Il est fortement recommandé d'avoir un script de construction qui emballe votre module dans un formulaire installable. Vous pouvez ensuite copier les packages installables dans le dossier Install/Module du site Web et obtenir l'URL /Install/Install.aspx?mode=InstallResources, qui installera les packages dans ce dossier.

Answer 2

Pour mon contrôle de source, je développe des modules dans leur propre projet. Cela contient le code du module, le code de test, le code du fournisseur de données (le cas échéant) et tout autre élément. Ceci est vérifié dans le contrôle de source comme n'importe quel autre projet. Notez que le projet de module ne contient aucun lien vers un site Web DNN spécifique et que les références DNN sont faites dans le projet dans un répertoire "bin" commun qui référence votre build cible. Par exemple, dans mon dossier de projets, j'ai \ bin460, \ bin480, \ bin510, \ bin520, etc. Chacun de ces dossiers contient un ensemble de binaires pour une version DNN spécifique. De cette façon, vous pouvez construire contre une version particulière, mais tester contre toute version que vous aimez.

Le problème avec la source contrôle d'un module en place dans une DNN installation est - parfois pas tout le code du module est facilement isolé sous un répertoire parent seul - ne prête pas bien à une approche du module PA - pas facile de déplacer le projet vers une version DNN différente pour le développement ou le test - source de commande de la solution DNN facile à utiliser par inadvertance, en particulier avec des solutions de contrôle de source VS intégrées.

Cette approche se compile rapidement car vous n'essayez pas de compiler l'ensemble du projet. Pour le déploiement de test, j'ai un script de construction qui copie les différentes parties du module dans un site Web cible. Cela peut être fait via la compilation (lier le script de construction) ou juste après que vous avez eu une compilation réussie dans une fenêtre cmd. Mon script de build a un switch d'environnement 'cible', de sorte que je peux dire 'dnn520' pour déployer la build à mon installation de test dnn520. Notez que vous devez d'abord créer manuellement la configuration du module avant que cela fonctionne, mais ceci est un effort ponctuel et vous pouvez utiliser la fonction d'exportation pour créer votre manifeste de module .dnn. Pour construire votre paquet de module, investissez le temps dans un script complet qui va prendre les différentes parties de votre répertoire source, et les zipper dans un paquet d'installation.Conservez toutes les parties de votre dossier de contrôle source et copiez-les dans un répertoire temporaire, puis exécutez un utilitaire zip de ligne de commande (j'utilise une ancienne version de pkzip) pour l'empaqueter dans un fichier installable.

Les avantages de cette approche est la suivante: - séparation du code du module de code installé - moyen simple de ne garder que le code du module de contrôle de code source (ne doivent exclure tout le code du site) - capacité à rapidement tester des modules dans différentes versions DNN - Script d'emballage vous permet de construire rapidement et facilement une nouvelle version d'un module pour l'installation de test/déploiement

les inconvénients sont - ne peuvent pas utiliser la magie bouton vert « go » dans VS (devoir attacher manuellement le débogueur) - plus de temps d'installation que de développer en place

Answer 3

En réponse à la réponse de bduke. Vous devez et ne voulez pas créer de projets dans le dossier DesktopModules.

1. C'est là où tout le code source pour le site va de soi.
2. C'est là que vos modules seront "installés" et donc si quelqu'un "met à jour" ou réinstalle un, il sera écrasé
3. Il peut rendre la mise à jour de votre application beaucoup plus difficile. Beaucoup de développeurs ne comprennent pas que l'idée de ne touche pas les fichiers de code source d'origine pour modifier leur comportement. PARCE QUE ce sera juste écrasé lorsque vous effectuez une mise à niveau.

Si vous voulez construire des modules, créez un dossier de solution appelée Modules et placez vos modules séparés de projet là-bas.

1. Si vous souhaitez les déboguer, placez le point de sortie de débogage cible dans le dossier web \ bin.
2. Si vous souhaitez les installer/déployer. Construisez-le en mode édition et installez-les via le filtre Module/Extension.