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.
Related
There are quite a few questions out there regarding this (for me, recurring) issue, but none of them have solved my problem.
Problem:
Whatever control I add in my aspx page, it is not recognised in the codebehind. Compiling doesn't work, because the ID is not recognised.
None of the following worked:
Clean and rebuild solution.
Close and open VS
Delete asp.net temp files
Check project's target framework.
Check assemblies are all there.
Check designer viewn to see if the control is actually there (it is)
Get control's ID with JS function to check it is the intended one (it is)
The problem has started only recently. In fact, I can reference the older controls fine.
The problem is observed both with standard ASP controls and Telerik ones.
Does anyone know of something else I should try? Please help me, I'm in the middle of a project and this is causing unnecessary delays, ta.
Make sure all of your asp.net controls (in the .aspx file) have the:
runat='server'
tag... Without this, you will not be able to reference the controls.
e.g.
<asp:Label runat='server' Text='Test Label' ID='TestLabel' />
Hope this helped...
Rodit
This is how I solved my issue. For a full account of it, please refer to the comments above.
I've noticed that although my project was already of web application type, designer files weren't showing.
I've forced the designer files to be recompiled by clicking on the ''convert to web application' option
I was then able to reference the control ID.
Thanks to the commentators anyway.
I was having a similar issue, due to the fact that I was using the pre-generated Login page. My solution was to change this section from this:
<asp:Login runat="server" ViewStateMode="Disabled" RenderOuterTable="false">
<LayoutTemplate>
To this:
<asp:Login ID="asplogin" runat="server" ViewStateMode="Disabled" RenderOuterTable="false">
<LayoutTemplate>
basically, I just added an ID to the asp:Login which allowed me to access the objects in the code from behind by prefixing the control name with asplogin
asplogin.youControlNameHere
I have an aspx document (I know nothing about asp, .net, aspx, nada). It is a normal html table structure for the most part, but there are strings of asp that seem to be inserting some sort of dynamic content. They are in the form:
<asp:Image ID="imgTopImage" runat="server" ImageUrl="~/Images/topbar.jpg" />
<asp:Label ID="lblStyleCaption" runat="server" CssClass="label_caption" Text="Theme: " Visible="false" />
<asp:DropDownList ID="dropStyles" Width="150" runat="server" AutoPostBack="true" />
It seems that whenever I delete one of these——something as innocuous as, say, the line with the asp:Image tag, which I would think should just remove the image, when I load the page I get run-time errors. It's very particular. My question is, is this compiled somehow, which is making it so fragile. Even just changing the topbar.jpg to something.png gives me an error. Do I need to track down the original files this was compiled from, or is this normal server-side asp(x?) that I'm just somehow else goofing up my changes to?
ASPX pages are compiled, and those tags refer to objects that are known to the server, so removing them could cause errors.
First, some basics in layman's terms
Tags that begin with ASP: (Example, <ASP:Button id="btnSubmit" runat="Server" Text="Click Me" />)
are not standard html buttons. They are server controls. When generating the html that goes out to the browser, the ASP.NET runtime looks at the server controls and creates the appropriate content depending on the browser visiting the page.
In the case of the Button control, it's usually a standard html button, but the runtime also generates the JavaScript and such to handle the button's server-side click event.
Why you're probably seeing errors when you remove a control:
Quite often, there's server-side code that's written that accesses these controls. For example, the developer may have decided to change the Text or the Visible property due to some event.
If this is the case, and you remove the <asp:Button> tag, then there will be server-side code that references an object that no longer exists in the aspx page, hence the errors.
More at these links on Server Controls:
http://www.w3schools.com/aspnet/aspnet_controls.asp
(Actually, this older one is better for a new-to-asp.net developer: http://msdn.microsoft.com/en-us/library/zsyt68f1(VS.71).aspx
http://support.microsoft.com/kb/306459
I'd also recommend taking some time watching basic videos or going through the tutorials at http://www.asp.net/get-started
I just noticed this in your question:
Even just changing the topbar.jpg to something.png gives me an error.
That is a bit odd, but I know of at least one way it could happen...
Generally, Visual Studio will give you a warning (and not an error) if you include a relative URL to an image or a linked page that doesn't exist. The warning shouldn't block you from compiling. However, Visual Studio does have a setting that tells it to treat warnings as errors. That will block it from compiling. Here's how that would be set up:
from Project Settings> Configuration Properties select the build
setting and change the “treat warnings as errors” settings to true.
If you wish to NOT treat warnings as errors, simply change the setting to false.
When I open an Webpage with SmartTarget configured, I am getting two different errors:
Error 1
First time I get this error:
Server Error in '/' Application.
--------------------------------------------------------------------------------
com/tridion/marketingsolution/profile/Contact
================================================
Some configured classpath roots cannot be found
================================================
ClassPath : C:\tridion\Publicationsites\TestRD\staging\bin\bin
I am not sure how Line 2, comes into the picture, but when I add another bin folder within the already existing bin folder, the error goes. Is something wrong with any of the config file?
Error 2
When I open the page after I apply the workaround for the above error, I receive the following error
Unknown server tag 'smarttarget:Query'.
<smarttarget:Query View="lister" AllowDuplicates="true" Timeout="5000"
Publication="tcm:0-14-1" runat="server" Id="as">
Line 3: <smarttarget:Item runat="server" TemplateUri="tcm:14-1319-32"
ComponentUri="tcm:14-1321"></smarttarget:Item>
Where do I need to add the smarttarget tag? Should it be in the web.config file? Can you please share the syntax. I have tried to accurately implement the ST as mentioned in the live docs. Any area that I need to recheck?
Question 3
I am pasting a screenshot of my Compound Page Template below:
When I publish this page, the HTML markup present in the Main Page Design TBB is not published at all. Only the markup generated by the Add SmartTarget to Promotion TBB exist in the aspx Page.
<smarttarget:Query View="lister" AllowDuplicates="true" Timeout="5000"
Publication="tcm:0-14-1" runat="server" Id="as">
<smarttarget:Item runat="server" TemplateUri="tcm:14-1319-32"
ComponentUri="tcm:14-1321"></smarttarget:Item>
<smarttarget:Promotions MaxItems="2" Region="sidebar" runat="server">
<ItemTemplate>
<smarttarget:PromotionalItems runat="server">
<ItemTemplate>
<tridion:ComponentPresentation runat="server"
PageURI="tcm:14-1119-64"
ComponentURI="<%# Eval("ComponentUri") %>"
TemplateURI="<%# Eval("TemplateUri") %>"/>
</ItemTemplate>
</smarttarget:PromotionalItems>
</ItemTemplate>
<FallbackContent>
<tridion:ComponentPresentation runat='server'
ComponentUri='tcm:14-1322'
TemplateUri='tcm:14-1323-32'/>
</FallbackContent>
</smarttarget:Promotions>
</smarttarget:Query>
Is my implementation correct ?
That's a lot of questions in one entry, but I'll try to answer them here.
Looks like you don't have the right Tridion home directory and it ends up checking 'bin' under the current directory instead. See my blog post on the subject on how this is figured out (and thus how you can solve it): How Tridion Content Delivery loads configuration files (.NET)
This is standard .NET functionality. You can define a prefix in the same page or, as recommended, in the web.config. The exact markup for the web.config is: <add tagPrefix="smarttarget" namespace="Tridion.SmartTarget.Web.UI" assembly="Tridion.SmartTarget" />
Only one "Output" item is used from the package (the last one added). So the way you've split up your Dreamweaver Templates currently would indeed mean that you only get the output from "ST Page Region". I don't know what the intention was with it, so I can't suggest a good way to solve it aside from getting rid of it and putting the tcdl:region directly inside "Main Page Design TBB".
Good luck with it :)
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.
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.