Vous êtes ici Forums
  |  Connexion
 Forums
HomeHomeForums DNNForums DNNDéveloppementDéveloppementPortage de module 3.x.x vers 4.x.x : problème de référence.Portage de module 3.x.x vers 4.x.x : problème de référence.
Précédente
 
Suivante
Nouveau message
16/10/2007 14:47
 

Bonjour,

Je suis en train de porter un module que j'ai développé en DNN 3 (ASP.Net 1.1) vers DNN 4 (ASP.Net 2.0).

Dans mon module version 3, j'utilisais une référence vers l'Assembly DotNetNuke.Modules.HTML, car j'ai besoin de la classe HTMLTextControler.

Dans DNN 4, cette assembly n'existe plus, car tout son code est passé dans le projet web "DotNetNuke", et la classe en question se trouve dans le répertoire spécial "App_Code". Hors, en ASP.Net 2.0, il n'est plus possible de référencer l'assembly d'un projet web, puisque les projets web sont compilés à la volée.

Comment peut-on pallier à ce problème ?

Pour info, je suis allé chercher la dll correspondant à cette classe dans le cache Temporary ASP.Net Files, et je l'ai référencée dans mon projet de module afin qu'il puisse compiler.
Mais à l'exécution, j'ai toujour une erreur, dans tous les cas :

- Si je déploie cette dll récupérée dans le bin du projet web, j'ai une erreur pour cause de doublons de tous les types référencés (en particulier ma class HTMLTextControler).
- Si je ne la déploie pas, j'ai une erreur à l'exécution pour cause de référence non trouvée !!


http://www.toulon.com (DNN 3 powered) // http://www.myspace.com/heaveninblack (mon groupe !)
 
Nouveau message
16/10/2007 16:01
 

Bonjour,

Nous avons rencontré ce problème également, et posé la question sur le forum officiel. Le thread en question sur Dnn.com n'a tjrs pas eu de réponse. Je crois cependant que Jean-sylvain a résolu.

seb

 
Nouveau message
16/10/2007 16:14
 

Effectivement, c'est exactement la même question que tu as posé sur le forum dnn.com... Jean-Sylvain ? Un aricien ? ou un forumiste français ?


http://www.toulon.com (DNN 3 powered) // http://www.myspace.com/heaveninblack (mon groupe !)
 
Nouveau message
16/10/2007 16:16
 

Les deux (et mon CTO). Il est en rendez-vous maintenant, je vois ça avec lui. Il aura peut-être fait différement, mais au pire tu auras un workaround.

seb

 
Nouveau message
16/10/2007 16:29
 

Super !! J'attends patiemment alors (en plus je vois que tu es actif sur mon second thread ;-) )


http://www.toulon.com (DNN 3 powered) // http://www.myspace.com/heaveninblack (mon groupe !)
 
Nouveau message
16/10/2007 16:50
 

Bonjour,

je pencherais pour la reflexion vu que le module est inclus dans le website DNN et n'est plus un module autonome. Donc ca veut dire plus d'utilisation par reference mais tout par reflexion (attention à gérer le cache pour les performances)


Enfin Seb confirmera dans un moment.


JB
 
Nouveau message
16/10/2007 17:02
 

Ouch... J'espérais ne pas devoir en arriver là, tout de même... Et si c'est le seul moyen, je suppose qu'il me faudra développer des classes proxy correspondant aux objets que je veux invoquer ?


http://www.toulon.com (DNN 3 powered) // http://www.myspace.com/heaveninblack (mon groupe !)
 
Nouveau message
17/10/2007 10:40
 

Salut, alors il existe une petite bizarrerie qui peut t'éviter la Reflection, mais nous avons quand même opté pour cette dernière solution pour plus de consistence, et du fait que pour un module simple comme text/html, un petit jeu de constantes sous la main rend le travail largement suportable:

Le Build Manager en charge de compiler dynamiquement les répertoires App_code de ton instance effectue ces compilations dans l'ordre des déclarations fournies dans le web.config, et tu peux donc utiliser le code des répertoires déclarés avant le tien, sachant qu'à l'install d'une PA, la déclaration du répertoire est rajouté en fin de liste et donc cela ne devrait pas poser de problème au déploiement.

Naturellement, ceci ne fonctionnera pas si ton module est développé en wap, puisqu'au moment ou tu compiles ce dernier, le module text/html n'est pas compilé; dans ce cas il te reste la reflection. 

D'autre part, ca reste un peu risqué, car si pour une quelconque raison le module source (Html) est désinstallé du portail, ton instance ne redémarrera plus.

Edit: petite nuance pour un module wap: si le code consommant le text/html est dans le fichier  de code behind d'un user control parent, tu peux tromper visual studio en sortant ton control du wap compilé comme indiqué dans le poste suivant: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/111/threadid/137842/scope/posts/Default.aspx

 


Jesse
Société de conseil et de service en 
informatique et systèmes d'information
 
Nouveau message
17/10/2007 11:10
 

Salut,

Merci pour ces réponses précises, je m'en vais donc de ce pas monter une classe qui "réflexionnera" les classes qui vont bien dans le TextHTML. Comme j'ai la maitrise du portail en question, aucun danger de désinstall...

En ce qui concerne les problématiques d'ordre de build, ou de config wap, je ne pense pas que j'aurai ce souci, je développe toujours mes modules dans un projet Class Library, et sans ouvrir le projet web ou le site web dotnetnuke  (j'utilise donc une solution totalement à part.

Mais puisque l'on parle des WAP, je crains être une victime de plus de l'impossibilité d'installer cette extension qui me serait pourtant bien utile. J'ai une version MSDN de VS2005 et d'après ce topic, c'est dommage pour moi : http://forums.asp.net/p/1009418/1370461.aspx


http://www.toulon.com (DNN 3 powered) // http://www.myspace.com/heaveninblack (mon groupe !)
 
Précédente
 
Suivante
HomeHomeForums DNNForums DNNDéveloppementDéveloppementPortage de module 3.x.x vers 4.x.x : problème de référence.Portage de module 3.x.x vers 4.x.x : problème de référence.