I'm having a strange problem in Visual Studio 2022, and would like to know if someone else faced it.
It only happens when editting .cshtml files, on Asp.net MVC projects, ocasionally when I press a key on the keyboard, the editor insert that same letter 2, sometimes 4 times. I need to restart my machine to solve it, but it will eventually return. The image bellow ilustrate the problem, I've typed <div> and got this result:
It doesn't happen on .cs, .js files, or in any other editor in my machine.
You most likely have GitHub Copilot activated. If so, try deactivating it.
I was going nuts with this too, until I found out that it was GitHub Copilot that was doing it once in a while. I have not found a solution to it, other than deactivating Copilot.
You can see a thread on it here: https://github.com/github-community/community/discussions/14206
Boa sorte ;-)
Related
My game was working fine all long for days. Recently just after adding attack animation for my enemyai it started freezing everytime I clicked on play.
So when I click play unity pops up with a message saying "Hold On ! Application.UpdateScene" and its stuck on that ever since. The only way for me to exit is using task manager.
Screenshot:
I tried debbing and adding break points but it did not work. At this point I don't know what wrong is it my code or something else.
I haven't updated my unity I am on 2020.1f but I don't think that might be causing the problem.
Also incase it's not possible to resolve this problem can you'll please tell me a way to complete my project quicker without redoing it everything.
Thanks
It is usually caused by a dead-loop.
I also has this issue today. I solved it by attaching the debugger (Visual Studio in my case) to the forever loading Unity Editor. After that, pause the debugger. This will freeze Unity but we can then inspect where the code is executing at this particular moment. Select the inspecting thread to "Unity Thread" in Visual Studio. In my case, it immediately show the code is running inside a while-loop which I forgot to increase the i variable and turn the loop into a dead loop.
The reason is just delete your Library package in your project folder then reopen your project unity recreate the file. The problem appears when you import assets from asset store.
Since I installed Visual Studio 2010 from scratch about 2 months ago, it behaves slightly different when debugging JavaScript code being run in IE.
When I set a breakpoint, it opens a duplicate of the view with the term "[dynamic]" in the header and marks the breakpoint in there.
When a JavaScript error happens during execution, it does the same before it marks the line of code that threw the error.
This "dynamic" view is editable but edits have no effect - they are not saved to the file.
I find this behavior pretty uncomfortable. Everytime I notice an error in the code during debugging, I happen to fix it in the dynamic view. I hit save. VS does not complain. Next I refresh the page in IE, and - bang - the changes are lost, it loads the untouched old version again.
I haven't been able to find out how I can turn these views off. Before I re-installed Visual Studio it did not do that. It would only create "dynamic" views for script found in inline script tags in HTML files.
Try this
IE > Internet Options > Settings (under browsing history) > Check for new version of stored pages : Every time I visit the webpage.
This works for me in IE10.
Other option is to open Developer tools and select cache option Always Refresh from Server as show in the image below
Try hitting CTRL+F5 on the web page. That did the trick for me.
The problem was that I had opened other IE windows from a previous debugging session, so the dynamic javascript files were still cached.
Having developer tools open - F12 - should also cause the cache files for the page to be cleared on each refresh.
Changing the encoding of the JS file in question, from a Windows codepage to UTF-8, fixes this for me.
Narrowing it down, it appears that OEM Extended ASCII characters in the file (e.g. ALT-254 which I use for a bullet) trigger the problem with the Windows codepage files.
(Visual Studio 2013 Update 5, IE11)
For Google Chrome:
Open developer tools(F12)
Open Network Conditions Tool
Select Disable Cache
I had the same problem of not being able to hit a break point in new code. And breakpoints on old code in the same page will bring up the [dynamic] version. The edited page is not reloaded. This just started for me a week ago in both VS2012 and VS2013. Using refresh page and/or Ctl-F5 did not work for me. BUT, reading this thread pointed me to using F12 to open Developer tools. Leaving that window open, while hitting refresh does the trick. Thanks guys.
1) Run the page Without Debugging (Debug-->Start Without Debugging)
2) While the web page is open in Internet Explorer, press Ctrl-F5 so
that the IE cache is cleared. Ensure IE has the focus.
3) Close IE and re-run the page with Debugging (Debug-->Start
Debugging).
This fixed the issue for me.
Most simply explained, when I edit, delete, or add code into my XNA project, it does not respond. This is to say that I can comment out the entire Update method of my game and it will run as usual. This also means that the game is stuck at a certain time in development, and can not be edited. I've tried reopening my project and it does not help. I've had this problem before and it is incredibly infuriating and frustrating.
http://puu.sh/1kD6P
This is an image where I have commented out the Update method and would normally never be able to run with 66 errors. But it does run.
In the past I have had to create new projects and drag all of my art assets over and copies of the code. That is the only way I know to fix it, but this has happened with every one of my projects (even on a different computer before).
Anybody know what's going on?
Have you tried rebuilding it from the build menu, not just clicking the debug button?
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