As stated in the headline, Visual Studio 2022 suddenly stopped showing errors (and also I can't find public method and variables but that's another question).
I am working in Unity and suddenly it just don't want to cooperate anymore.
I tried closing the application and unity all together and restarted my computer, and nothing worked.
At the top of your screenshot you can see "Miscellaneous Files". This means that the file is not considered to be part of any project.
To see errors and IntelliSense, VS requires source files to exist within a project so that it knows:
What references exist (packages, assemblies, target framework)
What version of the language is being used
Various properties that influence analysis/analyzers
So for some reason your file is not considered part of a project. We can't see your Solution Explorer, so it's not clear why that might be. Most likely you've opened the file via "File | Open". Make sure you create the file within a project, or add it to a project.
One of the endless joys of working with Visual Studio are random inexplicable times it stops working the way it should. Usually these steps work:
Close VS completely
Ensure all bin and obj directories of all projects are cleared
In the same directory as your solution should be a hidden .vs directory. Delete this.
Reopen VS and your solution. You should be back to a normal state within a few moments. Sometimes a "Rebuild All" can accelerate its return to normality too.
Related
I'm in the process of updating a library in a larger solution. For this purpose, I have removed the old references in all projects and added new ones.
If I compile the solution now I get about 3000 build errors, which indicate that various classes are defined in the old, removed libraries and I should add a reference to them.
After I have opened a reported file, Visual Studio recognizes that these classes are also included in the new libraries and removes the error.
Now I don't want to open hundreds of files to make these ghost errors disappear, especially because the problem repeats itself after the next build.
Does anyone have any idea how I can get Visual Studio to stop reporting ghost bugs?
I'm using Visual Studio 2022.
Intellisense will still give suggestions, but Visual Studio will not highlight any errors until I click "Start". I can write absolute gibberish and no red squiggles will appear. However, when I do click "Start", the Error List will finally populate and the build will fail. (It will also check errors after I click "ReBuild" or "Clean Solution").
However, when I do edit the errors, the red squiggles will remain. Even when I remove the entire line, a two space long red squiggle will remain. Clicking "Start", "Rebuild", or "Clean Solution" does not make these old error highlights disappear and the Error List does not change. Only closing and restarting VS 2015 Community will clear them. Rebooting the computer did not re-enable the error checking function.
System Details: This is a fresh install of Windows 7 Pro 64bit on a Macbook Pro with Bootcamp. This is the first project I have made since installing VS 2015 Community yesterday. I am writing a Windows Forms app using C#. To the best of my knowledge, it was working fine for a few hours this morning. I have already tried resetting all my settings. I have already tried rebooting and deleting the bin/obj folders in the solution directory.
Has anyone experienced such an issue? Do you think it is an issue with my install, or did my solution get corrupted somehow?
A few things to try that often fix weird Visual Studio problems:
Restart Visual Studio.
Delete the .suo file. This file should be right beside the .sln file, and is a temp file used for tracking things like which files/tabs you had open in the editor between sessions
Clear out some temp VS cache files.
Another thing you can try is running VS in safe mode to run with all extensions disabled. This may at least hint if the problem is native to VS, or if it's one of your installed extensions that is the problem.
Creating a new Project caused the error checking functionality to come back. I didn't even type any new code, I only made a new, blank project and everything started working again.
I have no idea why, but if someone else encounters this issue, make a new Visual Studio project and try re-loading your old one afterwards.
My breakpoints aren't getting hit in Xamarin Studio. I'm not sure if this has to do with my code, or not, but I feel as though it doesn't because I've tried over and over putting breakpoints all over my project (in places where I know they should definitely be hit, and in places that the code works perfectly and is completely unrelated to the feature I'm currently testing) and none of them are getting acknowledged when I debug. I don't have the breakpoints disabled, and I don't have them added in the wrong place. The breakpoints should work normally, and they're not. I'll also add that I'm not allowed to pause my application during the debugging process. I suppose you could say the debugger in my Xamarin Studio isn't working and I have no idea why. I believe I've determined it's unrelated to the code, but I can't be sure about that still. Please help. Thank you.
It is the most popular question about: "breakpoints are not being hit in xamarin" in google, so after whole day of trial and error I am gonna post here a solution for this problem for xamarin versions > 4.0.0.xxx. Yes, sadly this is simple.
SOLUTION
(This solution is for android app in visual studio, but should work in xamarin studio as well)
Remove all symbols from the path to your "Debug" Folder (usually: [path to your .sln file] \ [your solution name] \bin\Debug):
So if you got for example:
G:\My Files\Programming\C# (+ JS)\Test1\Examples\LINQ to Objects\AndroidDemo\AndroidDemo\bin\Debug
Change it to:
G:\My Files\Programming\CSharp\Test1\Examples\LINQ to Objects\AndroidDemo\AndroidDemo\bin\Debug
For me "(" and ")" symbols were causing the trouble (Who is using such symbols in the path anyway right?)
To verify that this is working, open your debug folder, in VIsual Studio Select "Clean Solution", "Recompile Solution", "Deploy".
"Deploy" action should generate *.mdb files which include your debugging data. If they are present, you should now be able to stop at breakpoints.
Now you can simply hit F5 like usual whenever you need to debug something.
I'm not sure if someone is still following this thread, but this workaround worked for me.
The problem sometimes has to do with the mono 5.
So the resolution is to use older version of mono:
Set "Project > Active Runtime" to "Mono 4.8.0 (8f6d0f6) (/Library/Frameworks/Mono.framework/Versions/4.8.0)".
for Mac users, change it in "Preferences" -> ".NET Runtimes"
Then Rebuild the Android app project.
Deleting the BIN folders and any *.SUO file is a favorite fix for this issue.
Can also try deleting any *.csproj.user
In worst case, reset VS Settings by launching (Run) with "Devenv.exe /ResetSettings"
Make sure you have your build configuration set to Debug.
Make sure your project's build settings are set to allow emitting DEBUG symbols for your Debug configuration.
Clean and Rebuild your solution/project.
Close and restart Xamarin Studio.
Reboot your computer.
Sometimes the build configurations for your solution can get complicated, and it's easy to miss something when building a complex build configuration. Make sure everything is setup properly in there.
I encountered this yesterday, using VS 2013 and Xamarin plugin. "All of a sudden" breakpoints in a PCL project were not active, even though breakpoints in an Android project still were. Everything had been working perfectly for weeks, and I had applied no updates. Looking at the VS Debug | Windows | Modules view, I could see that symbols were not loaded for the PCL assembly, and nothing I tried would force them to load, even though they were present in the folder with the running assemblies.
Then I remembered that the last thing I had done the prior day was not related to code, but was a bit of refactoring of csproj files to support a parameterized Jenkins build. I had placed an OutputPath definition in the first "shared" PropertyGroup, and removed it from all of the Configuration/Platform-specific PropertyGroups, e.g.:
<OutputPath>bin\$(Configuration)\</OutputPath>
I deleted this "common" OutputPath and put it back into each specific PropertyGroup (offending my DRY sensibilities, mind you), and things started working again.
This is probably not going to bite very many people, but it wasted a couple of my hours, so hopefully it spares someone else. The Xamarin build probably does some of its MSBuild/xbuild spelunking with strong expectations, so if you've modified your csproj files for a build process, this might be a possible culprit.
I add this answer because this is the only one that worked for me, in Project Properties > Build I wrongly checked Optimize Code.
Unchecking this box solved the issue.
I switched from stable to alpha Channel v.3.11.785 (Alpha). all breakpoints are now hit.
I faced this problem in Xamarin Forms app using Visual Studio for Mac. In my case, it was happened because of debugger. Visual studio was continuously showing "Waiting for the debugger to connect to the iOS simulator..." while running in an iOS simulator. I did reset the simulator (Hardware => Erase All Content and Settings) and cleaned up the solution. Then I could do the debugging with breakpoints. Hope this helps someone.
I had the same problem.
THE CAUSE (IMO):
In my case the problem is caused by Xamarin Studio (but with VS2013 is the same) build/rebuild process.
More in details, the *.mdb files are not correctly regenerated and therefore the debugger does not work properly.
You can check by doing a solution clean and going to bin/debug folder: if you still see *.mdf files then that's the problem in your case too!
SOLUTION
The only solution that works well is to manually delete all *.mdb files in bin/debug from all projects in your solution (so Android project and all PCL projects) and then do a Rebuild.
Let me know if this helps!
For me "(" and ")" symbols were also causing the trouble, I was searching for weeks for this problem. Remove the "(" and ")" in the full path, do a clean build and de breakpoints are hit again.
In my case, xamarin was not hitting any breakpoint. Red color rings were shown instead of filled red circles, because there were some syntax errors not able to be pointed out by xamarin, since I think solution build was not up to date, even I was able to run the app surprisingly. So I cleaned and build the solution, and it pointed out errors and relevant warnings after that. I fixed those, and ran the project. I was able to debug successfully after that!
If once the project launches on the device VS reverts to the standard editing mode (no debug options enabled in the menu) i.e. the debugger is not attached; check Project Properties > Android Options > Enable developer instrumentation is checked. For me the setting was disabled (most likely checked into source control after a release).
Use "Visual Studio for Mac" (Preview at the moment but works) instead of "Xamarin Studio". This fixed the problem for me. Breakpoints are working even in my PCL projects! Another thing... I had to change "project.json" (JSON format) to "packages.config" (XML format) when changing from "Xamarin Studio" to "Visual Studio for Mac".
I am having great problems running the application in the debugger from Visual Studio 2008.
When I'm using vshost.exe, it says:
And when vshost.exe is turned of, it simply states:
Interesting thing about it is that when i do use vshost, debugger is actually started and breakpoint is hit on the first line of the Main().
I tried:
rebuilding the project(s)
removing .ncb, .suo, .user for the projects
repairing Visual Studio 2008
changing the build architecture for the project
... no help there...
Any experience in (trouble)shooting that?
More info: some projects DO work, and one that I have to work on, does not.
I have some ideas such as:
trying to create NEW project, add thing by thing to it and see at what point it will start to miss behave
work it other way around, delete project by item by item to see when it will (if it will) be working OK again.
EDIT (for google, as I see that there are many similar questions on the web):
Errors:
Error while trying to run project: Unable to start debugging.
and
Error while trying to run project: Unable to start program '....\PlayKontrol.exe'
Try upgrading your Visual Studio to Service pack 1, if you haven't already.
Did you restarted your computer? You never know how windows will react to that :).
Also be sure there aren't any keys stuck, like the ctrl or windows key.
Note that the key does not have to be visually stuck, it can be stuck for visual studio and not for the explorer.
The most common source of sudden problems like this is corruption of one of the data files that vs uses to cache information between builds.
You've tried a clean build, but this won't delete everything. A real clean build is: quit vs, delete bin, obj, debug, release folders, delete all generated files in the root - primarily ncb. Do the same for any locally built libraries that you're project references.
The easiest way to do this is if you have the code in source control, as you can rename away your entire code folder and then force a get of all the source.
You often need to do all of these things in one hit to clear the problem.
Less frequently, a reinstall of vs will sort things out (although this sounds unlikely in your case if it is only one project that breaks)
Also think carefully about anything you might have installed just prior to it failing... And remember that some install effects may not occur until the next reboot so it could be days ago. A particular cause of this are automatic windows updates and trial versions of things like the vs 11 beta.
You might try running the application from outside of VS, but have a line of code that looks like this: Debugger.Launch(); where you want your first breakpoint.
I must have done something wrong. I have a C# project in Visual Studio 2008. All of a sudden I see a lock on my classes and when I hover the class names on the top tab I see the class name as : C:\Myprojects\Oder.cs[Read Only] !
Has something weird like that happened to you before?
In my case it was a ReSharper 9.0/9.1 related issue. After clearing the ReSharper cache, I was able to edit files in my solution again.
Clearing the ReSharper cache can be done here: ReSharper -> Options -> Environment -> General and click: Clear Caches and restart your visual studio.
(The image is contained within the first of the linked JetBrains articles).
JetBrains instructions:
Ultimate Guide to Speeding Up ReSharper (and Visual Studio) - Performance degradation after ReSharper upgrade
ReSharper Online Documentation
A couple of possibilities spring to mind:
Have you added the project to source control?
Have you marked the project folder (and all it's sub folders) as read only?
Of course, someone else may have done either of these things if they have had access to your machine.
One Possible stupid thing.
Your project is still running and you forgot that. Stop debugging (CTRL + F5)
How do I know. Guess..
Restarting my computer worked for me. My project became read only in between compiles - suddenly I couldn't save changes to files, Visual Studio started presenting me with 'save as' dialog boxes, and SVN couldn't commit or clean the project because "sqlite could not write to readonly database." Checking the file properties on the files in Windows Explorer showed that none of them were marked read-only. I was able to make a backup copy of the project, then I restarted and it was fine.
Restart your Visual Studio and add the project again. Worked for me.
Close, then reopen the file.
Still a pain, but at least it's less costly than completely closing visual studio.
You can try: file -> Source Control -> Go online
IDE-integrated source control?
Sounds like your source files are or have been under source control. Many source control systems will set files to read-only when they haven't been checked out for editing.
Total Commander makes it really easy to change file attributes recursively, but most likely Windows can also do this :)
Much in line with what Morten Mertner said, (if you by chance are using TFS Source Control like I am) I did a manual checkout of the file and it resolved the issue for me.
For me the problem is that the files are locked while the application is running.
In this state, Visual Studio 2013 displays the lock icon in the file tab and when you try to edit the file, a dialog box with this message appears:
Changes are not allowed for this module as it was not built for changes while debugging or the target .NET runtime version does not support it.
In Visual Studio 2015 as well, the lock icon appears in the file tab when the application is running. but the dialog box and message are not displayed.
Stopping the application causes the file to become unlocked.