The Visual Studio Error List shows like 50 errors about controls and variables not existing. I double click an error, it takes me to it, and after about 1 second they all go away!
There aren't any real errors, as my site compiles without errors or even warnings.
I know I've seen this before, but I forget how to fix it. Anyone know why this is happening? Thanks in advance!
I see it often too on web sites. I always have chalked it up to the compiler needing to "catch up" although I'm sure there is a more sophisticated answer to why that happens. It's annoying.
I've seen this before but I'm not sure what the actual cause is. I've seen it most using a website ASP.NET project rather than a web application ASP.NET project, but I don't know for certain that that's the cause.
That said, in my opinion you should use a web application style project anyway as it will pre-compile the most important portions of your application before deployment.
Related
I've recently implemented ELMAH in one of our production apps. It's really been a rather easy implementation and it's working flawlessly. However, I'm noticing the YSOD in prod isn't as telling as it is in dev. The main reason being that in prod we have Debug="false" and in dev it's true. We have a custom error page that an end user would see. What I would like to know is:
a. Do you also get the trimmed down YSOD because you don't run your app in debug mode?
b. Are you running prod with debug = true to see the "dev" YSOD?
c. Is there a configuration setting that will give me the best of both worlds?
EDIT: from the lack of responses, either I'm not asking the right questions (my MO on SO) or no one out there deals with this quasi issue. Not even a bounty can draw some responses?
You're right you are getting a cut down version as you are running with the debug flag set false. You have 2 options really;
Run the app in debug mode (albeit temporarily whilst you fix issues
Add Debug="true" to the Page directive at the top of the erroring page which should give you the full output for that page.
There is no halfway house unfortunately. FYI I run sites with debug=false enabling debug=true only when we have to debug errors.
I have an MVC application which uses a silverlight control.
Somewhere along the line something is happening in the silverlight cs code that isn't right. I've inserted break points in the CS silverlight code to get a better idea of what's happening, but for some reason I just can't step through the code.
I know code is being hit, but it's just not showing me in the debugger.
I thought it might be because I was using Chrome as the default browser but I changed this to Internet Explorer and still no joy.
I realize this is a very vague question, but has anyone else experience anything similar, and if so, how did you get around it?
Any help would be appreciated,
Thanks.
Be sure to set the Silverlight Debugging checkbox on the project properties Web tab
If Chrome is your default browser and your breakpoint tooltip shows this message:
"The breakpoint will not currently be hit. No symbols have been loaded for this document"
... then it is possible the debugger attached to the wrong Chrome process at debug startup. A work-around is:
Start debugging your Silverlight app. Your app should be running in Chrome.
From the Debug menu, select Attach to Process...
Scroll through the available processes and locate the chrome.exe process that shows the type as 'Silverlight x86'.
Select that process and click Attach.
I had firefox as my default browser and nothing was being hit(I even tried attaching to a process). What finally worked for me was setting IE as the default.
Silverlight break points are now being hit for me! :)
Right Click on Web.UI project in solution. go to Web , check Debuggers --> Silverlight save and Debug..
Make sure you have silverlight developer installed.
Your code may be part of a class marked with the System.Diagnostics.DebuggerStepThroughAttribute. This happens with auto generated classes (like with Add Service Reference). If you are extending a partial class, other parts of the class definition may have that attribute.
Try unckecking the Options / Debugging / General / Enable Just My Code checkbox.
Otherwise put your mouse over the red dot in the source code window, which becomes an empty circle if the debugger disabled it, a tooltip will give you additional information.
I want to completely remove "error list" from visual studio 2008, not disable it i want it gone. It annoys me to no end popping up endlessly, i guess i must be "doing it wrong" but w/e i just want to use VS without being alerted every other keystroke about some warning.
I've tried editing many different fields in the options (tools -> options) it has only slightly decreased the frequency of the error list popping up. I have also deselected errors, warnings, and Messages. and it pops up with nothing to display. unpinning it doesn't help either.
also upgrading to VS 2010 is not an option at this point.
Im looking for a solution something like the following: remove a dll or config file responsible for this
Also I still want the inline validation (the little squiggly marks, etc), but
the error list window annoys me.
I think this is probably exactly what you're wanting:
http://blogs.msdn.com/b/zainnab/archive/2010/05/16/hide-or-show-error-list-when-the-build-finishes-with-errors-vstiptool0022.aspx
You can change this behavior by going to Tools -> Options -> Projects
and Solutions -> General and deselecting the "Always show Error List
if build finishes with errors".
I'm guessing this will work with ASP.Net as well, since that's building on the fly.
I am using Visual Studio 2017, and I also have to cope with the useless, impossible-to-disable, annoyingly-in-your-face, and outright disturbing "Error List" window.
So, here is what I did:
Undock the "Error List" window to make it free-floating.
Resize it to the smallest size possible.
Move it out to some remote area of the screen where it is not so annoying.
And voila, problem solved ! (*1)
*1 Well, problem mostly solved. It will be completely solved when I abandon this dinosaur of an IDE.
My 'Error List' was constantly displaying also (VS2012). I also hate it.
I turned it off years ago, but today it just started appearing.
It was being caused a unreadable packages.config file. For some reason that reports it's fail state through the yukky 'Error List'.
Fixing the packages.config file stopped the 'Error List' from appearing.
for VS2017, select the "Build only" value from the drop down list in Error tab. Refer to the image below:
Hope this helps!
On Error tab, you have Errors / Warnings / Info buttons. Click on Errors button (de-press).
hope it helps.
I suggest turning off inline validation.
Yes, I know that you still want it. But, seriously, how important is it? It's trying to validate code that is half-written. How valuable can that be?
First of all, as-you're-typing code validation is distracting. It makes it harder to focus on the problem you are trying to solve. For example, writing a function with a non-void return will display the "not all code paths return a value" error continually until you get to the end of the function. In the meantime, the editor is telling you that there is a problem. I am sure that people learn to ignore these things over time (I have never kept the feature on for more than a few minutes after a new VS installation, so I don't know), but if you are actively ignoring something, then what good is it?
Second of all, any good that the validation would be capable of is unnecessary, because those errors will be brought to your attention at compile-time anyway. Having an uninitialized variable pointed out to you while you are thinking through the algorithm does not improve the quality of the code at all verses having it pointed out when you try to run the program. The variable is still going to be initialized either way. And there is an extremely high likelyhood that you are going to fix the problem before trying to run the code anyway.
So I just don't see the point of it. I suggest turning it off, and then your problem goes away.
UPDATE
As pointed out by #Charlie Kilian, there is a flaw in VS in which .aspx files are not validated at all, unless the "Show live semantic errors" option is enabled for C#, rather than validating those pages at compile-time as would be expected.
Therefore, editing aspx files will require turning this option back on for validation.
I guess I'll be going back-and-forth with it from now on. I hope they fix this in future versions of VS.
I still think that doing a semantic analysis and error-reporting on code that is actively being edited is a fool's errand. (Of course, I have also been known to write entire programs in notepad, just to see if I could get it to compile and run correctly the very first time without the crutch of Intellisense. It feels pretty awesome when it works.)
Selected answer is incorrect because unchecking "Always show Error List if build finishes with errors" does nothing to stop the dreaded Error List window from popping up on other errors, even if you change it to show only Build errors.
11 years later in Visual Studio 2022 it is still impossible to disable Error List window.
The only correct answer to the question "Completely remove error list from visual studio" is to uninstall Visual Studio itself which, thankfully, also removes Error List window.
Either that, or we should all get used to it, because Developer Gods from Microsoft want everyone to work in absolutely the same way as they do. Every workflow that differs from their own is wrong, and every thought that doesn't align with their grand vision is blasphemy.
It is One Microsoft Way or the highway.
(xkcd)
I know that compiling nowadays is much faster than it was before. Yet, for me, it seems that compiling and especially running/debugging ASP.NET projects with the Visual Studio Web Development Server is incredibly slow.
Since the beginning of last summer, I've been working heavily on ASP.NET MVC projects. Of course, the best way to debug them is by using the web server that comes with Visual Studio. When doing that, I get horrendously slow loading times. Chrome dev tools typically report that loading one of my pages had a 3 minute wait time, followed by a short loading time.
I've seen these two questions, but they don't help. While I do most of my debugging work in Chrome, the same happens in IE.
Has anyone else had this problem before? If so, any tips?
Also, I doubt that the problem lies with the speed of my machine. This computer is really fast running Windows 7 and Visual Studio 2010, so I don't see why ASP.NET debugging should be so slow.
UPDATE: In his answer below, Jon Skeet suggested attempting to identify whether the problem is being caused by the environment or by the code itself. I created a brand new MVC project and ran it. The first test appeared to be much faster. However, after testing it a few more times, it's safe to say that the first test was an anomaly - usually, it takes as long as my big project (2 - 3 minutes). Thus, this is a problem with the environment. Thanks in advance for any help!
UPDATE #2: It's been a while since I updated this question. Here are some details I've gathered since my last update:
This delay is occuring on both of my development machines, both running Windows 7 and Visual Studio 2010
This delay is happening for all my MVC2 and MVC3 projects (but I haven't experimented with plain ASP.NET yet)
Plain/vanilla MVC projects experience the same delay as MVC projects with big codebases
Disabling IntelliTrace did not help
Disabling IPv6 did not help
I haven't found a solution for this problem, so I've been stuck with huge wait times. Does anyone know how to solve this?
There's no reason why it should take 3 minutes to start debugging something unless you've got something really strange going on.
I suggest you launch the debugger, try to navigate to a page and then just break into the debugger while it's loading. See where you're losing time. Maybe you're making some call on startup which is failing, but taking minutes to do so.
I've never experienced anything like what you're describing, which suggests it's either in your environment or in your code - and if it's a generally fast computer, that suggests it's somewhere in the code.
If you create a brand new MVC project and debug into that, does that take a long time?
You might also want to run Wireshark when you start debugging - see whether something in your app is trying to fetch a network resource of some description without you realising it.
This is due to the IPv6 DNS problem within Firefox and can be fixed by setting the network.dns.disableIPv6 setting to true within the about:config
Slow DNS response - Firefox on localhost and Visual Studio or Cassini
This is actually a known performance issue with MVC, caused by throwing a ton of exceptions internally on startup. If you have IntelliTrace turned on, this will wreck havoc with it. Try disabling IntelliTrace and see if that improves it at all.
Source: http://connect.microsoft.com/VisualStudio/feedback/details/535799/debugging-mvc-is-very-very-slow
Check out if this helps:
http://blogs.msdn.com/b/mahuja/archive/2008/07/08/resolving-very-slow-symbol-loading-with-vs-2008-during-debugging.aspx
I met the same problem these days, working under Win7, VS2010, and developing a Silverlight solution with 10+ projects. It takes about 3 minutes to launch IE, and waits 3 minutes to get back VS after closing IE. I overcame the problem by trying different ways. But the only valuable method:
Unload all projects not for debug
Start debug the solution (it works normal )
Reload other projects
VS works normal here. (VS works normal)
It seems the problem is just related with the VS environment on my side. It has nothing to do with ASP.NET Development Server or IIS.
I was having the same problem. It ended up being a problem with ColdFusion being installed on my local machine (as painful as it is for me to admit). ColdFusion puts Handler Mappings named AboMapperCustom-* that were causing the latency. I uninstalled ColdFusion because I no longer need it (thank God). Another solution could be to remove each AboMapperCustom entry through the web.config. Example:
<handlers>
<remove name="AboMapperCustom-15397" />
<remove name="AboMapperCustom-20358" />
<remove name="AboMapperCustom-47286" />
</handlers>
Make sure the 5-digits following AboMapperCustom- match those in your local IIS Handler Mappings.
HTH
On Visual Studio 2012 + Win10 x64, i've noticed that if you
go to the taskbar and find the asp.net dev server there,
right click it and do a "show details"
close the box (NOT 'stop', just close via 'x')
then the server loads almost instantly
There's a famous bug in Visual Studio that prevents you from using the form designer on a subclass of an abstract form.
This problem has already been elucidated and solved most elegantly by Urban Potato; that's not the part I'm having trouble with. The trouble is, I have duplicated the technique described by Urban Potato, and included it in my project (which happens to be pretty big), and now every time I try to open the designer of my derived form, I get that Microsoft "frightfully sorry, old chap, but I'm going to have to kill you now" message (reminiscent of Otto in A Fish Called Wanda) that says "Microsoft Visual Studio 2005 has encountered a problem and needs to close. We are sorry for the inconvenience."
But here's the real kicker: if you just ignore that message, and stuff it away beyond the bottom right corner of the screen, you can carry on working, perfectly normally! Just don't click the "Send Error Report" or "Don't Send" buttons, coz then VS does close.
Still, this phenomenon is highly annoying, and I'd very much like to be able to work without the feeling that my IDE is just looking for some really nasty way to get back at me for pooh-poohing its sage advice to quit now - or else.
Further useful info: this same behavior can be duplicated on all other computers in my office; it's nothing specific to my machine. Obviously something in the project/code is upsetting the IDE, but at least I know the design pattern works, coz after I ignore the crash message, the designer works perfectly well. I just don't know where to start looking for the thing that is causing this problem.
Any ideas?
Thanks!
If it were me, I'd try attaching a debugger (maybe another instance of Visual Studio) to the instance that throws the error dialog, and see if the stack trace gives you any insights into what's causing the error.
The reason your are getting this problem might be that your base form is an abstracted class. The reason why the IDE will crashes is because the IDE tries to create an instance of the the abstract class which it cannot do.
It might be that you accidentally marked the internal class as abstract too.
Regards,
JvR