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.
I'm working on a project which creates large XML files of 800k plus. I was having memory issues so I changed my IIS option in Tools>Options to 64 bit which helped. The problem worsened when my project hung and wasn't responding so I closed it forcibly. When I tried to re-open from the project .sln it told me it was incompatible even though the Team Explorer showed my latest changes as below.
It produced a Migration Report which looked like this
The project folder layout looks like this
I've tried running old backed up folders but VS2017 always says they are not recognised and tries to migrate them, some are only three or four days old! Has this reset broken my Visual Studio, do I need to re-install? I don't really have the time to mess around with this but if I can't restore from GIT/Team Explorer or backups, i don't know how to get my project running again. It seems ridiculous that Team Explorer shows my latest changes but Solution explorer is blank!
Team explorer is only concerned with files on disk, it isn't trying to run anything. Solution explorer needs to open the solution file, read the contents, and interpret them in some way. It is failing to do this. This is why the former is working, when the latter isnt.
I find myself loading old C# solutions from VS2010 which have been upgraded to 2017. Thee appear to be a lot of baggage of folders and files coming along.
Is there a way to clean a solution that removes any unneeded files from old versions and only keeps what is being currently used? There may be old files that aren't even referenced any more in the solutions, but how do I know what is what?.
Basically when you attempt a conversion, generally Visual Studio creates a Backup directory to prevent the unintentional situations, as converted solutions or projects might be no longer compatible with Visual Studio versions that are earlier than current version of Visual Studio.
In Backup Folder, There should be an old version of your project.
If it works fine without original version of your project, you may delete whole "Backup" directory as you don't need them anymore.
If any project cannot be converted, it is unloaded and marked as unavailable in Solution Explorer. In this situation, address the problems indicated in the upgrade report as you try to reload the projects that are marked (unavailable), in this case, you may recover from your original project by open a project / solution file located in Backup folder.
Good luck with your project!
The way to clean is good old elbow grease so to speak. Simply remove a file from the project, or comment out a section of a file you think is not being used any more, rebuild. Put it back if build breaks or refactor it out rinse and repeat.
Of course with code files you can use Visual Studio's built in Find References to help as well.
A tool called Resharper can be used to deep cleaner faster, such as changing namespaces, renaming and finding all implementations but Visual Studio 2017 has all the renaming and reference finding you probably need.
Of course have all the code in source control, and incrementally commit every so often so you can revert a build you might break while removing files and not remember exactly everything you removed.
I'm trying out Visual Studio 14 CTP 2 and noticed there's this .sln.ide folder:
There have been a few questions going around about the .sln.ide (see this, this and this), but two of them are about a file (not folder) with that extension in Visual Studio 2012 (not 2014), and the remaining question is unanswered.
From the hints I've seen in those questions, it appears that the folder is created by the Roslyn compiler for caching purposes. However, I've been unable to find a source that explains exactly what it does.
So what is the purpose of that folder, and how is it used?
It
...is used by Roslyn Compiler engine to store temporary files.
See: http://blogs.msdn.com/b/webdev/archive/2014/06/03/announcing-web-features-in-visual-studio-14-ctp.aspx
As my inspect, Visual Studio 2015 RTM never use this folder again, you can delete it. If you had used .tfignore/.gitignore to ignore .sln.ide, you can delete it too. Cause it won't be generated anymore.
It now uses hidden .vs folder, with the same files in .vs\(solution name)\v14\vbcs.cache. Some of them have .vs\(solution name)\vbcs.cache, I believe it has been used in some preview versions of VS 2015, already been replaced by v14\vbcs.cache and can be deleted too. And also you can delete (solution name).v14.suo because it's been replaced by .vs\(solution name)\v14\.suo.
I'm using VS 2008. When ever I make a change in my code and try to compile I get the following error:
Error 7 Unexpected error creating
debug information file 'C:\Documents
and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.PDB'
-- 'C:\Documents and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.pdb:
The process cannot access the file
because it is being used by another
process. ' DispatchBoard
Using Process Explorer, it is always devenv.exe that is locking the file. If I run in Release mode this does not happen. It started 2 days ago when I started a WPF application, and since then it happens with every application I work on.
The only info I could find from Google was referring to a bug in VS 2003.
Anyone else have this problem? How do I fix it? It is getting very annoying having to kill the file handle every time I want to compile.
If you have multiple instances of VS open, close other instances (apart from the one you are trying to compile) - this may resolve the issue.
When I have problems with locked files, I use Unlocker. (If you tried everything and it's not working, try this ;)
In case of broken link, here's a mirror.
Have you tried closing VS, deleting obj folder then restarting VS?
I had the same problem this morning and noticed that I had another project open that had a reference to the one that would not compile or debug. I removed the reference (as I didn't actually need it) and it was fine.
I changed the 'StartUp Project' of my solution to a project without reference to the locked file's project.
This solved the issue for me using VS 2010 SP1.
(Process Explorer said msvsmon.exe (started by devenv.exe) locked the pdb file.
After changing the startup project the processes msvsmon.exe and .vshost.exe disappeared and so did the file handle.)
Alex Clark, thank you for pointing me in the right direction.
The only thing that worked for me is to remove the optimizeCompilations="true" attribute from on the compilation element in my Web.Config file.
Compilation time may be a little longer, but it worked well.
To avoid that problem just open the project properties, go to Debug tab an untick "Enable the Visual Studio hosting process"
I had this issue today. In my case, I had just grabbed the data from my company's source control and instantly hit this issue when I tried to compile the project. The issue ended up being that the \bin folder was set to Read Only. To solve the issue, I just made the folder not Read Only.
I just came across the same problem today. And then I realized what went wrong: I had couple of Visual Studio windows opened at the same time, and one of them was in debug mode.
When I stopped debug mode in that one, the problem was solved.
That happens when you have a "fistfull of VS windows" opened.
Right Click The Folder that contains debug .pdb and uncheck the folders read-only propertys then ok. thats it.
This works for me with web projects in Visual Studio Express 2012 for Web:
Press F5 to begin debugging
"Do you want to execute last successful build?" - hit YES
At this point you could try a request - not sure if this step is necessary
Hit the stop button
Recompile successfully
I have solved a similar problem by adding these lines as a pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
With proper modifications, it might help your problem.
Since you say you have it on all applications you work on it sounds like a more global problem. You could try and reinit the vs2008 by writing
devenv.exe /setup
Edit: link to command line options
This worked for me. What I done was that close my visual studio and delete the .suo file and then re-open the solution. The locking should be disappeared now. Cheers.
Old topic, but something that worked for me. I had 2 projects in my solution, a class library type project and a windows form project. The windows form project was referencing the compiled binary and not the project itself in my case which was causing the lock. After changing the reference to the class library project, it worked properly.
Not need to restart or delete the file.Deleting will not be possible , you will get error message. Just rename the file and that is enough.
VS2010 will create another file for you as it wont find the origional. :)
I had the same issue from time to time. Usually no problem but once in a while... This particular time, it was impossible to work. I would shut the application down, and even that didn't work most of the time. I saw this post and a person said they had no issues until they started a WPF application. I was playing music (radio station) in the background with Windows 8 "Music" app. I had the idea that it was a Microsoft App built with Visual Studio. Once I stopped playing music, I never encountered the error. If you are reading this, see if you have any Microsoft apps running.
I also had the same issue. Tried all the suggestions above with no luck. I eventually change the Build Configuration from Debug to Release, the solution built...
This problem started occurring for me after changing from Cassini to IIS Express as my platform for debugging.
Cassini was much better than IIS Express but doesn't properly support the Integrated pipeline. IIS Express is hopeless.
This seems to be some sort of race condition in Visual Studio or IIS Express. It is nothing to do with one project locking another project - the locks are coming solely from the activity of the web application's build process.
Anyways, none of the above solutions worked for me. Unlocker doesn't seem to be supported for Windows 8 anymore. So instead I tried LockHunter. What I do is keep the LockHunter app open all day. If I get a complaint about some file being locked I copy and paste the file path into LockHunter then try again. This usually sorts out the problem but sometimes takes a few attempts.