Ton exception semble bizarrement plutôt suggérer qu'une procédure stockée n'est pas à jour (GetContacts en l'occurence), mais pour l'histoire des dlls, il faut en effet d'une part recompiler le projet si tu as modifié les classes, et d'autre part migrer les dll dans le répertoire bin du site web, ce qui peut se faire de plusieurs façons:
- dans les paramètres du projet, en définissant de façon relative le chemin de compilation pour toutes les configs
- Utiliser un projet visual studio factice et de confort, dont le répertoire cible de compilation est le répertoire bin de DotNetNuke, et qui se charge simplement de référencer tous les autres projets pour en déplacer les dlls à chaque recompilation. C'était la méthode employée dans la solution vs 2003 de DNN 3.X
- en disposant dans ta solution du site web ainsi du projet du module (j'imagine une projet de lib ou un wap) et en faisant référence ton projet de module par ton site web (modifie le web.config, puisqu'il n'y a pas de projet à proprement parlé). L'inconvénient est que le site web met généralement longtemps à compiler
- en ajoutant un événement de post-compilation pour déplacer les dlls
Tu pourras également, si tu souhaites rajouter de services et des contrôles additionnels à l'avenir et modifier les ascx principaux, utiliser avantageusement le système de compilation dynamique qui te permettra de rajouter des fonctionnalités à l'avenir sans besoin de recompiler. (Il te faut pour cette fois recompiler le code que tu as changé car il fait partie de la dll)
Pour rappel un module dynamique est compilé dynamiquement avec DotNetNuke; un répertoire de code de couche métier placé dans le répertoire App_Code et déclaré dans le fichier web.config est compilé au démarrage de l'application et son contenu peut être appelé dans les contrôles du site web qui sont compilés dynamiquement à l'exécution.
Le principal avantage est la possibilité de modifier le code sans besoin de recompiler manuellement une dll du répertoire bin, et donc sans redémarrage laborieux de DNN; et mieux l'Edit and Continue est possible en Débug (attache/détache le processus w3wp de l'isapi Asp.Net de IIS).
Pour cela, tu peux passer tes ascx des formulaires principaux (Portalmodulebase) en "CodeFile" dans la déclaration, tu met à jour la propriété de compilation du fichier de code behind à none dans visual studio. Tu recompiles ton projet de module .
Dès lors, tu peux sortir le projet de ton visual studio et développer directement dans le site web en mode dynamique, tout en t'appuyant sur le noyau dans la dll qui devra être référencé pour compiler dans Visual Studio, mais encore une fois; tu n'as pas à compiler à chaque modification, ce fait gagner beaucoup de temps.
Au besoin, tu pourras réintégrer tes classes depuis le répertoire App_code dans le projet pour un packaging final après débug.
Voilà pour un petit aperçu des différentes façons de développer sous DNN, la difficulté parfois ressentie au démarrage vient sans doute partiellement du fait que nombre de projets de modules remontent encore à l'ancienne génération, et que les deux façons actuelles de développer des modules peuvent prêter à confusion.
J'espère que mon explication éclaire en quoi elles diffèrent et peuvent se compléter.