Come faccio a sbarazzarmi di __o non viene dichiarato?

Question

ho qualche codice nella mia pagina master che istituisce un collegamento ipertestuale con un po 'di contesto le informazioni sensibili

<%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--> 

Ora il problema sembra essere nella parte href. Se rimuovo il codice dinamico, l'errore scompare. Qualcuno può dirmi come risolvere questo problema?

Answer 1

Ho trovato il numero answer nei forum .net. Contiene una buona spiegazione del perché ASP.Net agisce così com'è:

Abbiamo finalmente ottenuto una replica affidabile e identificato il problema sottostante. Un banale Repro assomiglia a questo:

<% if (true) { %> 
    <%=1%> 
    <% } %> 
    <%=2%> 

Al fine di fornire IntelliSense in <% =%> blocchi in fase di progettazione, ASP.NET genera l'assegnazione a una variabile __o temporanea e la lingua (VB o C#) quindi fornire il intellisense per la variabile. Ciò avviene quando il compilatore di pagine vede il primo blocco <% = ...%>. Ma qui, il blocco è dentro il se, quindi dopo il se si chiude, la variabile esce dall'ambito. Finiamo per generare qualcosa del genere:

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

La soluzione è aggiungere all'inizio un'espressione fittizia. Per esempio. <% = ""%>. Questo non renderà nulla, e farà in modo che __o sia dichiarato di primo livello nel metodo Render, prima di qualsiasi potenziale 'if' (o altra definizione dell'ambito).

Una soluzione alternativa è di usare semplicemente

<% response.write(var) %> 

invece di

<%= var %> 

Answer 2

Sì, ho riscontrato lo stesso errore occasionalmente in pagine che utilizzano costrutti lato server su pagine ASPX.

Straordinario, ho trovato una soluzione per questo (mi dispiace, non sono stato in grado di scoprire dove ho trovato questo bit di informazioni di nuovo.) E quella correzione è di mettere il seguente codice sopra il errante <%...%> blocco:

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

a quanto pare, in cui si inserisce il codice sopra riportato fa la differenza per VS.NET, quindi potrebbe richiedere alcuni tentativi per farlo bene.

Answer 3

Dopo alcune ore di googling e l'analisi mucchio di aspx'ses nel mio progetto attuale sembra che ho trovato la soluzione, che sta funzionando per me. Sarebbe di consigliare vivamente evitare commenti HTML in stile:

<!-- ... -->

pagina interna aspx. Invece di esso uso aspx in stile commenti

<%-- ... --%>

Inoltre mi ha aiutato ottenere che vs intellisense e il codice evidenziazione divenne lavorare di nuovo e soprattutto cosa - questo caso avevano iniziato da esso - vs possono ora colpire i punti di interruzione all'interno pezzi incorporati di codice vb/cs! E nessun maledetto messaggio "Questo non è un luogo valido per un punto di interruzione".

Answer 4

Questa è una soluzione strana, ma per me sono riuscito a risolvere questo problema semplicemente chiudendo i file aperti incriminati in Visual Studio.

Con loro aperti, stavo erroneamente ottenendo il problema __o.

Non appena li ho chiusi, il problema __o è scomparso.

Answer 5

Quando ho pulito la soluzione, ho riavviato IIS ed è ancora misteriosamente in riproduzione, a mio avviso questo può essere causato dall'incollare un contenuto del file di origine ASPX da un altro sistema in Visual Studio che aggiorna "utilmente" il codice, possibilmente cambiando alcuni ID e rompendo la pagina.

Incollarlo in un altro editor (Notepad ++?), Quindi il salvataggio impedisce a Visual Studio di "essere utile" e la pagina funziona di nuovo.