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?
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 %>
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.
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.
After some hours of googling and analyzing bunch of aspx'ses in my current project seems I've found the solution, that is working for me. Would to advise strongly avoid html-style comments:
<!-- ... -->
inside aspx page. Instead of it use aspx-style comments
<%-- ... --%>
Additionally it helped me obtain that vs intellisense and code highlighting became working again and the mainly thing - this case had begun from it - vs can now hit the breakpoints inside embedded pieces of vb/cs code! And no any damn "This is not a valid location for a breakpoint" message.
When I've cleaned the solution, restarted IIS and it is still mysteriously playing up, I find this can sometimes be caused by pasting an ASPX source file's contents from another system into Visual Studio which "helpfully" updates the code, possibly changing some IDs and breaking the page.
Pasting it into another editor (Notepad++?) then saving it stops Visual Studio from "being helpful" and the page works again.
Related
Agree my question is duplicate of this one and accepted answer works for me too. Let me clarify why.
When I have <%= in head it gives error.
When I have <%= in body it works.
When I have <%# in head it works.
I am just curious to know the reason for all three scenarios.
Additionally I created test project to emulate the issue but in that case all three situation works.
My page is too big and I am unable to decide what code to paste.
<%= %> is in fact doing Response.Write, which is literally writing symbols to the response. To the final markup that is.
Now notice that your head tag has this attribute runat="server". That makes it a server control. That is, this is not a final markup, and but rather a control that will output some markup to response during the control rendering stage. You cannot call Response.Write on this control, because it is not a final markup yet.
For the same reason it would work/not work in the body of the page. If you put it somewhere in plain markup it would work no problem:
<div><%= "Blah" %></div> <%-- works! --%>
But as soon as it appears inside anything with runat="server" you'll get an error
<div runat="server><%= "Blah" %></div> <%-- error! --%>
<asp:Panel runat="server"><%= "Blah" %></asp:Panel> <%-- error! --%>
Now <%# %> is a different beast. This is a data binding markup, something that is being evaluated when the server side control is being data bound. Thus is makes no sense (and is invalid) inside plain markup, and can be used whenever your control is bound to some data. Using it with header is not very common, use cases with GridView or Repeater are the most typical ones that come to mind.
Every once in a while, when I'm editing an aspx or ascx page, Visual Studio will start telling me there is an error on the first line of my file. For instance, right now, it is saying Argument missing on line 1. That line is just your typical header, with no apparent problems (to my eyes), and I hadn't even changed that one when the error started appearing.
<%# Control Language="C#" AutoEventWireup="true" CodeBehind="MyControl.ascx.cs"
Inherits="MyNamespace.MyControl" Debug="true" %>
Unlike most compile errors, the build still succeeds. (At least this time it did.)
It's worth noting that no other errors or warnings are thrown by this file or its as[p|c]x.cs
Sometimes, to get out of it, I am forced to undo my changes until it disappears and carefully redo what I wanted. This time, grasping at straws, I cleaned and rebuilt the solution. While I was typing this, the error disappeared, sometime after the rebuild finished.
I have a suspicion that it often happens when I tinker with the databinding in my markup. Sometimes it seems to appear if I'm missing a space inside a tag before its closing slash, like so:
[...] Text='<%# Eval("Field") %>'/>
versus:
[...] Text='<%# Eval("Field") %>' />
...But that doesn't seem to have been the problem in this case.
When coding PHP and Perl, sometimes the interpreter would throw an error referencing the very last line of the file. Over time, I learned to look for imbalanced brackets and other delimiters somewhere up above. This problem in ASP.NET feels similar, but stranger, since it's the first line, and not just something amiss above, cascading down to the bottom. Or is it just Visual Studio getting temporarily confused? Can any pros shed some light on this problem, with reasons why it happens? I'd like to have some logic (as opposed to my own built up superstition) to throw at this the next time it rears its ugly head.
Here is what I found - when I get this error there is usually a code in the aspx page with a function call that is in fact missing arguments - like this one
<asp:DropDownList DataValueField="Value" DataTextField="Text"
runat="server" Width="90%" ID="Duration"
DataSource='<%# Utils.GetDropDownList(, ) %>' />
Note that arguments are missing in the call Utils.GetDropDownList(, )
So the error message does not correctly point to the line in aspx page, but there is in fact an issue with the code.
Hope this saves somebody some time.
Having observed this a few more times now, it seems like this happens when a Rebuild of the solution is in order. I tend to use Build most of the time, because it's conveniently mapped to F6. (I'm not currently aware of a built-in mapping to Rebuild.) Remember to use Rebuild when things are going strangely awry.
I've run into an issue where a third-party component appears to be interfering with Response.Write and causing any content within Response.Write("") to render before any of the other html. For example:
<html><head><title><% Response.Write("HELLO WORLD") %>
will render as
HELLO WORLD<html><head>...
However, any content rendered using <%= %> blocks will work correctly. The below code will work perfectly:
<html><head><title><%="HELLO WORLD"%>
I always assumed that <%= was simply shorthand for Response.Write. From what I've been able to find on MSDN I now understand that it <%= is eventually converted to Response.Write, but apparently there are a few steps inbetween.
Does anyone have a guess as to why the two would render differently or point me to some documentation/info that explains how <%= %> blocks are handled?
Update: The control that was causing the issue was the Telerik AjaxManager control from the 2009 Q1 release. Upgrading to the Q2 control resolved the problem.
Unfortunately I don't have access to the source so I haven't been able to figure out why the control was causing this behavior. The issue has been resolved but I am still very curious as to why it existed in the first place.
<%= "foo" %> is turned into Response.Write("foo"); once it is compiled. You can verify this by digging through the ASP.NET Temporary Files folder and using Reflector to decompile the dll's you find.
Can anyone explain what might be causing this error. Im thinking its the quotes.
Exception Details: System.Web.HttpRequestValidationException: A potentially
dangerousRequest.Form value was detected from the client
(ctl00$ContentPlaceHolder1$DetailsView1$txtContent="...l economy.<br /><br />The
Prop...").
The contents of a control (probably a textbox) contains what ASP.net considers to be markup, eg:
<br /><br />
You can add ValidateRequest="false" to the Page directive in your .aspx file as follows:
<%# Page ........ ValidateRequest="false" ........ %>
As other answers noted, asp.net is doing this to try and protect you from potentially malicious input so make sure you're aware of the risk and encode/decode user data appropriately.
I think you can take a look at this A potentially dangerous Request.Form value was detected
Its the html "<br/>" tags.
Here's an article with a brief explanation . Also shows you how to work around it by turning off validation. Though I guess that would be a bit dangerous to just turn it off.
It actually should be
<br /><br />
it complains about.
That would be the '<' and '>'.
EDIT: It's assumed that including html entries in form responses is intended as an attack on the server on which the form resides. So, by default, any code that resembles html (i.e. includes '<' or '>') is automatically flagged as a problem.
One way to resolve this is to turn off this type of validation by setting validateRequest="false" in the Page directive for that page, but there are other (and better) ways to work around that.
Here's some information from Microsoft about this issue.
My idea: allow this exception to be thrown. Use Application_Error handler to write code, that redirects (using Response.Redirect - this is important, since this gives users’ browser ability to go back) user to a custom error page. On this page write some text explaining that users had incorrectly input some text. Something like:
"Dear user, you have entered some invalid text, like “<” or “.”. Please, enter text using only characters and numbers".
Put a link on that page, and this link can contain a javascript "back" command:
href="javascript: history.go(-1)"
Users after clicking suchlink will be redirected by their browsers to the previous page, where they can re-edit their input.
A simple question, I think:
I want to put a tag into an ASP.NET app I've been asked to maintain, so I'm coming at this from a newbie point of view just tinkering around the edges without knowing a lot.
I wrote an old ASP application back in 1998, so I am just running on memory...
How do I write some output to the webpage?
I know I can use an
<asp:label id="blah">
but then I need to define a Label blah; in my code behind and then assign it.
I believe that I can put in-place:
<% Response.Write("sometext"); %>
and that will write sometext in the location within the page. (Am I correct?)
Lastly, I remember there was a syntax to the effect of
<%= "some string" %>
but I can't find the documentation on it, to say either it is deprecated, unadvised, or the rationale for such a decision.
I have tried googling for "ASP.NET grammar" but I can't even find a good description that "<%=" even exists, though it is mentioned in a few blogs.
For something simple, like inject the global version number, or the current date, then I can't see anything particularly wrong with in-place composition - it would save me defining 15 labels and having to initialise them all - though perhaps the asp:label approach could reference one global instance of a label?
Just asking for opinions on good practices :)
<%= string %> is perfectly valid ASP.NET syntax. The reason you will often find references to problems with using that is people use <%= (equivalent to Response.Write) when they should use <%# (for databinding) or vice-versa.
For example, we use it very extensively in our content managed site, where we pull in values from a global settings repository:
<%= SiteContext.Current.GetSetting("SiteTitle") %>
MSDN:
MSDN entry on <%= (this is under the JScript.NET section but still applies)
MSDN entry on <%#
Some others suggest <%= is not a "best practice" or a very good approach, but I strongly disagree with that sentiment. For an MVC-ish type site (especially a site that is template- or view-driven in some way), the most direct approach is frequently more effective than using server controls.
Just be mindful that when you use an <asp:Label /> it renders the .Text inside the <span> tag whereas an <asp:Literal /> adds no extraneous HTML to the string passed to it.
For example, if you were building a content management system and wanted to display user-driven HTML, a Label control would not correctly display the output from a WYSIWYG type rich textbox whereas a Literal control is the appropriate choice.
The <%= %> is the late-bound equivalent of the Literal's .Text property. The only difference here is when the value is placed in the page (aside from obvious syntax and separation of concerns paradigm) during the course of the page lifecycle.
Since the .Text property is on a control inherited from WebControl, it can be set/read/manipulated during any of the events following the control's Load event (wherever/whenever you load the control inside the page), but the <%= %> text cannot be directly read/used/manipulated by the code-behind without referencing some other control to get to it (like a containing div's InnerHtml property).
There are lots of options. You could use a single label, and string concatenate all the data you want displayed in that location.
You could create a user control with the layout you want and assign values that way.
You could inject it directly with response.write or the <%= %> syntax
You could create an HtmlGenericControl in your code behind (it's a div), add some text to it, and inject it into the pages controls collection.
Whatever you pick, try and go with the existing style of the coded page.
Look up the term "render blocks" for the <% %> syntax.
How about using
<asp:Literal id="z" text="goofy" runat="server" />?
Labels are usually used with forms.
You can also take full control of the rendering of your pages and controls and compose whatever you need to. You control the HTML, the order of rendering your controls, etc...
Go with the <asp:label /> (or a literal control if you want to customize some html in the content). Seriously. I'ts not that hard: when you put label in your markup visual studio will create it in the code-behind for you, so there's no extra work involved.
You could use the <%= "some string" %> syntax in web forms, but there can be issues when mixing that with the asp controls and there's a good reason new frameworks moved away from mixing logic like that in with your markup.