Bonsoir Myriam,

la procédure de mise à jour est assez simple dans les faits, mais peut être un peu délicate pour certaines montées de version. Je ne crois pas de mémoire que ce soit le cas depuis une 4.6.2 vers une 4.7, mais voilà quelques conseils qui devraient à l'avenir t'éviter de mauvaises surprises.

• Avant toute chose, effectue un backup de ta base de données et une copie du répertoire racine de ton site, au cas ou quelque chose tourne mal
• Si ton site est en production ou du moins si d'autres utilisateurs sont suceptibles d'accéder à ton site pendant la mise à jour, alors modifie dans le fichier web.config à la racine de ton instance le paramètre autoupgrade pour le passer à "false", afin d'être sûre que toi seule déclanchera la requête de mise à jour. Ceci te permettra également de mettre à jour "à chaud", ie sans arrêter le site qui affichera temporairement un message d'inaccessibilité jusqu'à ce que la mise à jour soit effectuée.
• dezippe le fichier d'upgrade dans un répertoire temporaire, il s'agira par la suite de copier l'ensemble de son contenu par dessus ton installation existante, en faisant naturellement attention à copier dans le bon répertoire, c'est à dire la racine de ton site web, mais garde ça pour le dernier moment.
• Le seul fichier qui peut demander une mise à jour manuelle et qui peut être délicate est le fichier web.config, qui doit refléter les dernières modifications du noyau, ces dernières dépendant de la montée de version. Tu peux donc copier le fichier web.config de ton site dans ton répertoire temporaire, histoire d'y effectuer d'éventuelles mise à jour sans toucher à l'original.
  Le plus simple pour mettre à jour un tel fichier est d'utiliser un outils de comparaison de fichiers, tel que winmerge qui est gratuit et fonctionnel.
  
  Le package upgrade n'inclu pas de fichier web.config afin de ne pas écraser le tien au cas ou tu dézipperais directement dans ton site, ce que je déconseille histoire de bien décomposer la procédure.  En revanche, il doit contenir un fichier developement.config et un fichier release.config, qui servent de référence pour la mise à jour de ton fichier web.config.
  
  Si tu compares dans winmerge l'un de ces fichiers et le fichier web.config de ton installation, tu risques de constater beaucoup de différences  qui n'en sont pas vraiment et qui ne te simplifieront pas la tâche. Ceci est du au fait qu'à la première installation, dans le cadre de la mise à jour initiale du fichier, tous les retours à la ligne et autres espaces blancs prévus par les membres du core team pour en faciliter la lecture ont été suprimés. Pas pratique...
  
  Mais avec un peu de bonne volonté on peut faire avec.
  • Si tu demandes dans les préférences de winmerge à ignorer les espaces blancs, les différences sont déjà un peu plus lisibles.
  • Une possibilité est de comparer directement le fichier Release.config (ou Developement.config selon) de l'upgrade avec le fichier du même nom qui a du être conservé dans ton répertoire d'installation si tu ne l'as pas supprimé. Winmerge devrait te donner les différences exacts, que tu peux dès lors appliquer manuellement dans ton fichier web.config.
  • Une autre possibilité si tu parts d'une version assez vieille (ce n'est pas ton cas cette fois) est de repartir d'un fichier neuf en copiant et renommant l'un des fichiers xx.config fourni (comme tu avais du le faire à l'install) et d'y reproduire les personnalisations spécifiques à ton install si celles-ci étaient peu nombreuses: tu devrais avoir besoin d'y mettre à jour:
  • les 2 chaînes de connexion (attention aux commentaires pour les versions sqlserver/sqlserver express),
  • les deux clés d'encryption qui ont été regnérées aléatoirement dans ton web.config lors de l'installation, et que tu dois reporter, ainsi que le paramètre "installationdate" correspondant, afin que dnn ne tente pas une regéneration (attention, ces clés permettent entre autre de décoder les mots de passe utilisateur, et il est important de les conserver sous peine de ne plus pouvoir se connecter; normalement un backup de ton fichier a été créé automatiquement dans le répertoire install).
  • le sqldataprovider si tu as modifié le paramètre "objectqualifier" ou "dbowner" (attention, la encore un mauvais paramètre risque de corrompre définitivement ta base de données), et d'autres providers que tu aurais modifiés
  • les noms des cookies (optionnel)
  • l'élément subcode directories si tu as installé des modules dynamiques
• Une fois ton fichier web.config à jour dans ton répertoire temporaire, tu peux copier l'ensemble de son contenu par dessus ton répertoire d'installation. Dès lors, une requête vers ton site devrait te renvoyer un message d'indisponibilité (du fait que l'"autoupgrade" est désactivée, sinon l'upgrade se lance automatiquement)
• Pour déclancher la mise à jour, saisie l'url suivante: http://[racinedetonsite]/install/install.aspx?mode=upgrade
  Tu verras apparaître l'écran de mise à jour avec les messages validant les différentes étapes
• Si jamais quelque erreur a été signalée dans l'écran, un fichier de log détaillant l'erreur a du être crée dans le répertoire install. La plupart du temps, tu peux quand même te connecter sur ton site, et tu pourras alors consulter le fichier de log correspondant dans le formulaire Host/Configuration, tout en bas de page (sélectionne la version correspondant à l'érreur signalée).
• Il te reste de façon optionnelle à mettre à jour les modules de ton instance. Le package upgrade ne les comprends traditionnellement pas, contrairement au package install.

Voilà à peu près tout me semble-t-il. Je pense en ce qui te concerne que le web.config ne devrait pas contenir trop de modifications, peut-être même pas du tout (il n'y a qu'une version de différence).

++

Salut Gilles,

tu n'as pas mentionné le repport du paramètre "installationdate", est-ce qu'il n'est plus utilisé (je n'ai pas vérifié dans la dernière version)? Sinon, il est déterminant pour ne pas déclancher la regénération des clés.

Sinon, ta procédure correspond à mon paragraphe "Une autre possibilité si tu parts d'une version assez vieille...". Je crois qu'on est a peu près en phase.

Je préfère quand même généralement faire ces modifications dans un répertoire temporaire dédié plutôt que directement dans le site, histoire de ne pas avoir à arrêter le site le temps de modifier le fichier.

Nickel ! C'est fait ! Je n'ai eu aucun problème

Un grand merci à vous pour vos instructions car sans ca j'aurais vraiment eu du mal

J'attend avec impatience les traduction fr de DNN 4.7

Encore un grand merci !

Myriam

Il s'agit de app_offline.htm, qui en effet intercepte toute requête asp.net si elle est présente à la racine du site.

Depuis une poignée de version, désactiver l'autoupgrade présente donc une page du même type, alors qu'auparavant on avait le droit à un joli message d'erreur pointant la différence de version entre la dll DotNetNuke et la base de données.

Je joins mes remerciements à ceux déjà présents.

Cela fait quelque jours que je cherche une explication simple sur comment upgrader DotNetNuke.

Cette discussion devrait être mise en sticky.

Cdlt

Stephane