是什么导致短暂的 aspx 第一行编译错误?
每隔一段时间,当我编辑 aspx 或 ascx 页面时,Visual Studio 就会开始告诉我文件的第一行有错误。例如,现在,它在第 1 行显示 Argument Missing
。该行只是典型的标头,没有明显的问题(在我看来),而且我什至没有更改该标头错误开始出现。
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="MyControl.ascx.cs"
Inherits="MyNamespace.MyControl" Debug="true" %>
与大多数编译错误不同,构建仍然成功。 (至少这一次是这样。)
值得注意的是,该文件或其 as[p|c]x.cs 没有抛出其他错误或警告。
有时,为了摆脱它,我被迫撤消我的更改,直到它消失了并仔细地重做我想要的。这一次,我抓住了吸管,清理并重建了溶液。当我输入此内容时,错误消失了,在重建完成后的某个时间。
我怀疑当我修改标记中的数据绑定时经常会发生这种情况。有时,如果我在结束斜杠之前缺少标签内的空格,似乎会出现这样的情况:
[...] Text='<%# Eval("Field") %>'/>
与:
[...] Text='<%# Eval("Field") %>' />
...但这似乎不是本例中的问题。
在编写 PHP 和 Perl 代码时,有时解释器会抛出引用文件最后一行的错误。随着时间的推移,我学会了在上面的某个地方寻找不平衡的括号和其他分隔符。 ASP.NET 中的这个问题感觉很相似,但很奇怪,因为它是第一行,而不仅仅是上面的问题,一直层叠到底部。或者只是 Visual Studio 暂时感到困惑?任何专业人士都可以阐明这个问题,并说明其发生的原因吗?我希望有一些逻辑(而不是我自己建立的迷信)来在下次它抬起丑陋的头时抛出它。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是我发现的 - 当我收到此错误时,aspx 页面中通常有一个代码,其中的函数调用实际上缺少参数 - 就像这个注意,
调用中缺少参数
Utils.GetDropDownList(, )
因此,错误消息没有正确指向 aspx 页面中的行,但实际上代码存在问题。
希望这可以节省一些时间。
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
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.
现在已经多次观察到这种情况,似乎在重建解决方案时就会发生这种情况。大多数时候我倾向于使用“Build”,因为它可以方便地映射到 F6。 (我目前不知道到 Rebuild 的内置映射。)当事情出现奇怪的错误时,请记住使用 Rebuild。
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.