[.NET] [Résolu] Problèmes de Usercontrol

Dev
1

Bonjour,

J’ai un soucis concernant les usercontrols, après avoir épuisé notre bon ami Google sans résultats probants, je me tourne vers vous.

Petit récap de la situation, pour info :
J’ai repris il y a quelques semaines un projet au boulot : un certain nombre de sites faits en .NET (certains 3.5, d’autres 2.0 et même 1.1) avec pour but à terme de tout refaire dans un autre langage. Or, on a eu besoin de modifier un poil l’existant (en gros pour faire de la récupération de données, en gros 2 requêtes à coller dans le code). Mon soucis, c’est que je n’ai jamais touché à .NET donc j’ai des problèmes, disons, de base, sur les configurations.

Voilà donc le coeur du problème (pour info, j’ai Visual Studio 2008 et le site que j’essaie de générer tourne avec le framework 3.5) :
Le projet utilise AjaxControlToolkit qui doit filer un certain nombre d’items AJAX, or à la génération du site j’obtiens l’erreur suivante :
« Balise server inconnue ‹ cc1:modalpopupextender ›. »

modalpopupextender étant bien évidemment un des items fournit par Ajax Control Toolkit.

Voici la ligne incriminée :

<cc1:modalpopupextender id="ModalPopupExtender1" targetcontrolid="LinkButton2" popupcontrolid="ConfirmDelete" cancelcontrolid="btCancel" backgroundcssclass="modalBackground" dropshadow="true" runat="server"></cc1:modalpopupextender>

Rien de folichon.
L’appel de ce usercontrol se fait de la façon suivante :

<%@ Register assembly="AjaxControlToolkit" namespace="AjaxControlToolkit" tagprefix="cc1" %>

Sachant que AjaxControlToolkit.dll se trouve dans mon dossier « bin », ce qui, si j’ai bien compris, devrait faire qu’il est compilé lors de la géénration du site et que ce qu’il contient soit bien compris dans les pages.

Donc ma question, c’est : où est ce que ça cloche ?

Est ce qu’il y a des choses particulières à spécifier dans le web.config ? Est ce qu’il faut enregistrer la référence à AjaxControlToolkit (ce qui est fait à priori) ? Autre chose ?

Merci d’avance pour le coup de pouce, les infos, les liens :slight_smile: .

PS : Pour info, j’ai déjà regardé les videos de Joe (ou John je sais plus) Stagner sur l’installation de ce toolkit, j’ai tout suivi à la lettre, etc… Donc à priori c’est bien installé

2

Toutes les lignes de code que tu cites se trouvent dans un même fichier .ascx donc ?

Ensuite, pour la balise Register, je te conseillerai de mettre le nom complet de l’assembly dans l’attribut assembly.

Un truc du genre :

Tu devras peut-être modifier le numéro exact de la version, à checker dans les propriétés de ta référence (clic sur la librairie dans la liste des références)

3

Bon et bien c’est résolu.
Merci styx de ta réponse, même si ce n’était pas ça.

En fait, les fichiers du projet se trouvaient sur notre serveur de développement (en réseau local donc) et du coup, Visual Studio n’arrivait pas à publier le site. En rapatriant, les fichiers sur ma machine ça a fonctionné.

Résolu donc, mais tout de même un poil amer. J’avoue que je ne comprends pas bien pourquoi VS à cette exigence, surtout pour un site web. En l’occurrence ça ne dérange pas plus que ça, mais si on était plusieurs à bosser sur ce projet, ça ne serait pas spécialement pratique. Si quelqu’un a une explication… :slight_smile:

4

L’explication se trouve dans la gestion de la sécurité de .net.

En gros les droits que possède une assembly sont définis fonction de son emplacement. Différentes politiques s’appliquent selon l’emplacement du fichier. Pour t’en rendre compte, il te faut aller dans les outils d’administration => Configuration Framework 2.0.

Va faire un tour dans la partie “Runtime Security Policy”, “Machine”, “Code Groups” et enfin “All_Code”, qui liste les zone de sécurités déclarées.

Et il existe un ensemble de règles pour les assemblies chargées depuis un partage réseau (LocalIntranet_Zone).

Les contraintes imposées par défaut sur cette zone font que visual studio n’a pas suffisamment de droits pour pouvoir charger les librairies de la manière dont il le souhaiterai (en gros il veut du full trust). VS n’aime pas de telles références, donc il est possible que ca fasse ensuite merder le système de publication.

C’est ce système qui permet de référencer directement une dll par son url internet et pouvoir ainsi l’utiliser dans une appli (mais avec les contraintes de sécurité données).

5

Merci beaucoup pour toutes les précisions :slight_smile: