Bonjour Jean-Marc,

Concernant l'erreur @SystemList, il faut vérifier ce que fait le module dans les fichiers .SqlDataProvider. Ce sont des fichiers texte contenant les commandes T-SQL pour créer/modifier les tables et procédures stockées du module. Le fait qu'ils fassent directement appel à des procédures stockées de DNN montre qu'ils n'ont pas compris ou voulus appliquer les bonnes pratiques de dev.

Par nature, la base de DNN et ses procédures sont appelées à évoluer au fil du temps (heureusement). Il ne faut donc JAMAIS faire directement référence à celles-ci. L'exemple typique est une jointure dans une sproc de module avec une table DNN. Si jamais cette table change, la sproc ne fonctionne plus ! Il faut donc juste maintenir une référence vers l'id ciblé dans ses propres tables, puis faire appel aux méthodes de l'API pour retrouver les données correspondantes MEME SI CELA EST PLUS LONG ! :-)

Trop souvent, sous prétexte qu'ils ont les sources de DNN, certains développeurs "tapent" directement dans le code ou dans les éléments sous-jacents comme les tables et sproc. C'est la toute dernière chose à faire avant de se jeter sous un train ! Car alors ce développement se coupe des évolutions futures du système et par là même créé un fork sans le savoir. Dans ce cas, l'instance de DNN ne peut plus être mise à jour et expose parfois les utilisateurs de l'application à de graves failles de sécurité.

Je n'ai pas le détail de "l'affaire ASPDotNetStoreFront", mais il faut savoir qu'il s'agit d'une application ASP.NET autonome qui a été portée sous DNN 4.x. Manque de chance, il semble que les développeurs n'ont pas suivi certaines régles de développement. Or, lors de la sortie de DNN 5.x, ils ont compris qu'ils ne pourraient pas faire une simple mise à jour et sont allé au clash avec DNN Corp. J'affirme que ce n'est pas un problème lié à DNN mais bien à la façon d'utiliser un framework quel qu'il soit. Ils auraient eu exactement le même problème avec un Jomla, Drupal ou tout autre CMS. Pour preuve, le module Store officiel que je développe depuis plus de 3 ans maintenant fonctionne parfaitement avec toutes les versions depuis DNN 4.4.1 (4.6.2 pour les dernières béta) jusque la dernière 5.6 !

Je comprends que toutes ces explications ne t'arrange sûrement pas ! :-( Je précise tout ceci pour que tu comprenne bien que tu risque d'avoir pas mal de boulot à faire pour porter correctement ce module vers DNN 5.x ! Je ne peux pas me prononcer formellement n'ayant jamais utilisé ce module. Peut-être serait-il plus simple de chercher un autre module avec des fonctions équivalentes puis de faire des exports/imports des données entres les différentes tables directement dans SQL Serveur.

Gilles