How do i get rid of __o is not declared?

I have some code in my master page that sets up a a hyperlink with some context sensitive information

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

Now the issue seems to be in the href part. If I remove the dynamic code the error disappears. Can anyone tell me how to resolve this issue?

Solution 1:

I've found the answer on the .net forums. It contains a good explanation of why ASP.Net is acting the way it is:

We have finally obtained reliable repro and identified the underlying issue. A trivial repro looks like this:

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

In order to provide intellisense in <%= %> blocks at design time, ASP.NET generates assignment to a temporary __o variable and language (VB or C#) then provide the intellisense for the variable. That is done when page compiler sees the first <%= ... %> block. But here, the block is inside the if, so after the if closes, the variable goes out of scope. We end up generating something like this:

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

The workaround is to add a dummy expression early in the page. E.g. <%="" %>. This will not render anything, and it will make sure that __o is declared top level in the Render method, before any potential ‘if’ (or other scoping) statement.

An alternative solution is to simply use

<% response.write(var) %>

instead of

<%= var %>

Solution 2:

Yes, I have experienced the same bug occasionally in pages that use server side constructs on ASPX pages.

Overtime, I found a fix for it (I'm sorry, I just haven't been able to find out where I found this bit of info again.) and that fix is to put the following code above the errant <%...%> block:

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

Apparently, where you put the above code makes all the difference to VS.NET, so it may take a few tries to get it right.

Solution 3:

This is an odd solution, but for me I managed to fix this problem by simply closing the offending open files in Visual Studio.

With them open, i was erratically getting the __o problem.

As soon as I closed them, the __o problem disappeared.