Sometimes after editing some parts of a razor source file, the editor crashes with tons of errors like the following screenshot:
It fails to recognize these external components from NuGet packages and other source files.
This problem has been around for quite a while. Since it could be simply fixed by reloading the project, I didn't pay much attention to it at first. However, it started to appear frequently recently, I have to reload the project every few minutes, which is really annoying.
Maybe someone has also encountered this problem? It sucks to have to reload the project all the time!
To be mentioned, I'm using ReSharper 2021.3 along with VS2022, but ReSharper's global analyzers still work fine when VS's crashes.
Related
I have a Blazor application using Visual Studio 2019 version 16.10.4. Every time I publish to an IIS server using the Publish... command from the Solution Explorer, Intellisense stops working in the .razor file that I have open and all text coloring goes away, so that all the text becomes the same color (and all auto-indentation stops working). If I close the .razor file and reopen it, Intellisense and colors start working again.
Is that a known issue, or is it a problem that I can fix? I've seen other posts about Intellisense not working in Blazor, but those all seem to be older posts with older minor version numbers of Visual Studio, and they don't mention the problem occurring only when publishing.
This kind of thing happens all the time. The solution is to jiggle it a little bit: close and re-open the file, restart VS, delete bin files, etc. etc.
In Blazor, there are a couple other common culprits. EventCallback with a declared Type often complains that it can't covert the type, even though if you ignore it, it will still compile and run.
It appears a fix is coming for this. As much as it's a frustrating issue, at least it will be resolved soon.
https://github.com/dotnet/razor-tooling/issues/5103
I was coding with razorpages when randomly about 2 days ago the razor pages now display boths the cshtml and cs right away. earlier I could expand the cshtml to get to the cs file and i think it was a more compact that way
i think its options somewhere in tools->options->environment () but there are so many
after a few different google searches I found nothing helpful.
here is a picture of the problem:
earlier I could expand the cshtml to show the .cs files now i just see all of them and its kind of overwhelming.
enable file nesting in solution explorer
They're not being nested, is all. It's literally two separate files, Visual Studio just recognizes that it's a Core project, and then shows them nested, since it understands that they're related. If that's not happening, then that means Visual Studio doesn't recognize it as a Razor Page, which could be a problem with VS, the project, or something else entirely. It's essentially impossible to say what the issue might be, so you'll just need to try stuff. A few things I can think of to try:
If you're not using VS 2019, upgrade. Ultimately, this is part of the ASP.NET Core tooling, and best version of that is always going to be in the latest release.
Verify that you solution is building correctly. You might also consider deleting all bin and obj directories and rebuilding to ensure the build is truly up to date.
Close Visual Studio completely and re-open it. You may consider restarting as well. (You've probably already tried this though).
Try running Visual Studio in "safe-mode", which essentially just means disabling all the extensions you have installed. You can either manually disable all your extensions and then restart or close Visual Studio and start it via the command like with devenv /safemode. If this fixes the issue, then there's an extension causing issues. You'll probably need to just disable each one by one to see which on is causing the problem, and then either remove it or see if there's an update that corrects it.
If all else fails, repair Visual Studio. Run the intaller, and click the "More" link under the installation you're working with. Then click "Repair".
Yesterday i had worked on this solution and ran it with debugging enabled perfectly well on two systems yesterday, and today i tried debugging it and it took about 15 minutes for the window to even appear. I didn't change any settings, change any code, etc. Ran it with the exact same build as the day before, on a different system yes, but both systems ran the code perfectly fine yesterday. Now they take an extremely long time to even start and once finally started it is unusably slow in debugging mode. Note, this doesn't happen when i disable debugging. I've tried multiple things, such as cleaning, rebuilding, deleting .suo files, and more. I am wondering how to fix this problem which i think primarily has to do with visual studio's debugger, my project, or my solution, as this doesn't happen with any other projects.
I am using Visual Studio 2017, and this slow debugging is only the case for this project.
I figured it out accidentally when changing the 'enable native debugging' setting on. Having it on was making the debugger load a lot of .pdb files that i didn't need.
We're working with a solution which has multiple projects which references NuGet packages from other solutions.
Every time we do get latest from the TFS server on the solution, Visual Studio (2015) starts reloading each project in the solution which takes a really long time. Now this wasn't always the case, since this started happening only a few weeks back (the solution is a year old).
We have other solutions which were already experiencing this problem and our solution is to close the solution, then do get latest, then reload the project which is much, much faster.
Can anybody explain why this is happening and how to fix this issue?
This has been reported as a bug to MSFT, see Slow project reloading & Reload of projects is slow after call to TFS to get latest changeset. It seems your project files are updated from outside VS, which causes VS to load all them. More details please see the reply from VS IDE team:
Main culprit is, your project files are being updated from outside
VS, which causes VS to load each of them one by one. This is
extremely taxing process and it happens on the main UI thread. Hence,
this ASL logic is on-by-default to alleviate unresponsive solution
loads. Essentially, you’re pointing out a limitation in our ASL logic
that we hadn’t considered. This will be considered for a future
release, thank you.
In the meantime, one way to mitigate the problem would be to force
solution reload by touching the solution file, the *.sln file, which
will trigger ASL to kick in, basically VS thinking you’re doing full
solution load and it will optimize responsiveness time as much as
possible.
Ulzii Luvsanbat
Visual Studio IDE Team
Please try these steps:
Open Visual Studio installer and install the most recent available update for 2017 version.
Open %localappdata%/Microsoft/Team Foundation/7.0/cache and delete all files, then restart Visual Studio and retry.
Yesterday I wanted to continue working on a project of mine, so I started Visual Studio and asked it to run the project to remind myself, what was already implemented and what wasn't.
The project got built and started, but seemed to quit right away. No error message, nothing.
No matter what I did, whether I rebuilt the project or cleaned it, nothing changed.
This didn't make sense, since the last time I tested the project, it worked perfectly (and I didn't modify anything in the code since then)
So, I assumed I had a hidden bug somewhere in the code, that just didn't show up previously.
I put a Breakpoint somewhere near the beginning of the code, and ran the project.
As expected, Visual Studio paused the execution at the Breakpoint and highlighted it.
I decided to set another Breakpoint somewhere later in the code and continue execution, but before I could even move my mouse, the project stopped.
Restarting Visual Studio didn't help, but restarting the PC did. Therefore, I'm assuming that something on my system was terminating my project, shortly after execution begun.
Now my question is: What exactly happened, and especially: why did it happen?
The problem came back while I was writing this question. I don't feel like restarting my PC every couple of hours...
I really appreciate the time you took reading this and I look forward to your answers.
I'm aware that I'm answering my own question, but since I've solved it myself, I thought others might want to know how I did it (for the sake of future generations)
The thing is: I've recently added Visual C++ to Visual C# before Visual C# started having problems.
So I deduced, that maybe the installer for Visual Studio messed up with something and decided to reinstall Visual Studio.
Problem solved.
So: if your projects stop without warning even while paused on a Breakpoint and you've changed something in your Visual Studio installation (like added Visual C++ in my case), you might need to reinstall the whole thing.
Luckily, the Visual Studio installer offers a "Reinstall" option, so you don't need to uninstall and reinstall manually.
I found about this solution, after talking to a more experienced colleague. I just wish I asked him first. Still appreciate your efforts in the matter, though.
EDIT:
I recently noticed a similar bug acting up for C++ programs this time, where the window border would be outlined in red. The thing is: it's not Visual Studio's fault, but in fact Avast Antivirus' fault. More specifically, its Sandbox mode.
So, if for any reason, you notice programs quitting without crashing, shortly after starting and their window border having a red outline, you're very likely using Avast Antivirus and should deactivate the Sandbox mode.
Happens to me from time to time.
Sometimes closing and opening VS helps, sometimes you have to restart the computer.
I assume it must be related to some DLL or something that is loaded into memory and corrupt, or something like VS loosing the reference to it, and not unloading it correctly/replacing it.
I also once had this strange bug, where I started VS, just like any other day, and my project crashes instantly with some H_RESULT error (some DLL related Error) upon run. After having spent around 1hour searching for the source of the problem, I went into the reference section, and what did I see there : the worst possible circular reference ever : my business project had a reference to ... itself ! The kind of stuff you could not do if you wanted to.
The weirdest part of this, must of been that VS managed to compile the project, and it only crashed while trying to run it ...