Comment puis-je me débarrasser de __o n'est pas déclaré?

Question

J'ai un code dans ma page principale qui établit un hyperlien avec des informations sensibles au contexte

 <%If Not IsNothing(Profile.ClientID) Then%>
<span class="menu-nav"> 
<a  target="_blank" 
    href=
"http://b/x.aspx?ClientID=<%=Profile.ClientID.ToString()%>&Initials=<%=Session("Initials")%>"       
    >
    Send
    <br />
    SMS
    <br />
</a>

</span>
<%End If %>

<span class="menu-nav"> <!-- Name __o is not declared Error is flagged here-->
 

Maintenant, le problème semble être dans la partie href. Si je supprime le code dynamique, l'erreur disparaît. Quelqu'un peut-il me dire comment résoudre ce problème?

Answer 1

J'ai trouvé la réponse sur le .forums du net. Il contient une bonne explication de pourquoi ASP.Net agit à la façon dont elle est:

Nous avons enfin obtenu fiable repro et identifié le sous-jacent question. Un trivial repro ressemble à ceci:

 <% if (true) { %>
<%=1%>
<% } %>
<%=2%>   In order to provide intellisense in <%= %> blocks at design time, ASP.NET generates assignment to a temporary __o variable

et de la langue (VB ou C#) puis l'intellisense pour les variable. Ce qui est fait quand la page compilateur voit le premier <%= ... %> le bloc. Mais ici, le bloc est à l'intérieur de la si, donc après si ferme, la variable est hors de portée. À la fin nous devons générer quelque chose comme ce:

   if (true) { 
        object @__o;
        @__o = 1;
   }
   @__o = 2;

La solution de contournement consiste à ajouter un mannequin expression précoce dans la page. E. g. <%="" %>. Ce ne sera pas tout rendre, et il fera en sorte que __o est déclaré haut niveau dans la méthode Render, avant toute possibilité de " si " (ou d'un autre établissement de la portée) de la déclaration.

Une solution alternative est d'utiliser simplement

<% response.write(var) %>

au lieu de

<%= var %>

Answer 2

Oui, j'ai parfois rencontré le même bogue dans des pages qui utilisent des constructions côté serveur sur des pages ASPX.

Heures supplémentaires, j’ai trouvé un correctif (je suis désolé, je n’ai tout simplement pas été en mesure de savoir où j’ai trouvé cette information.) Et cette solution consiste à placer le code suivant au-dessus de l’erreur <%...%> bloc:

 <%-- For other devs: Do not remove below line. --%>
<%="" %>
<%-- For other devs: Do not remove above line. --%>
 

Apparemment, l’emplacement du code ci-dessus fait toute la différence pour VS.NET, il faut donc peut-être quelques tentatives pour le réussir.

Answer 3

C'est une solution étrange, mais pour moi, j'ai réussi à résoudre ce problème en fermant simplement les fichiers ouverts incriminés dans Visual Studio.

Quand ils étaient ouverts, je rencontrais de manière erratique le problème __o.

Dès que je les ai fermées, le problème __o a disparu.

Answer 4

Après quelques heures de recherche sur google et analyse des tas de aspx'ses dans mon projet actuel semble que j'ai trouvé la solution, c'est de travailler pour moi. Serait à conseiller fortement d'éviter html-les commentaires de style:

<!-- ... -->

à l'intérieur de page aspx. Au lieu d'utiliser aspx commentaires

<%-- ... --%>

En outre, il m'a aidé à obtenir que vs intellisense et la mise en valeur du code est devenu de travailler à nouveau et le principalement chose - cette affaire a commencé à partir d'elle - vs pouvez maintenant atteindre les points d'arrêt incorporé à l'intérieur des morceaux de vb/cs code! Et pas de n'importe quel putain "Ce n'est pas un emplacement valide pour un point d'arrêt" du message.