I have an application that reads from a user settings file, typically stored in Users/{username}/AppData/Local/{publisher}/{app}/{version}/user.config. I want to test making changes directly to the file, not through the Visual Studio properties editor.
I found this answer to a different question that points to where the application is supposedly loading the file from, but it doesn't seem to exist when I check during a debug session in Visual Studio.
For example, when I run the following in the Immediate window when stopped on a breakpoint, it fails to find the file.
System.IO.File.Exists(System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath) //returns false
My reason for wanting to find this file during debugging is that I have received reports of the config file being corrupted and crashing the application in production. I'm sure that I can return that file to a default state, but I want to actually reproduce the problem in a debug environment.
How can I find the settings file loaded by Visual Studio?
I'm not quite sure what changed between when I posted this question and now, but today the code in my question returns true. But to answer the specific question I asked, the user.config file was in a very similar path to a standard installed application.
Standard application:
Users/{username}/AppData/Local/{publisher}/{app}/{version}/user.config
Visual Studio debug application:
Users/{username}/AppData/Local/{publisher}/{app}.vshost.exe{some_hash_value}/{version}/user.config
I have searched and found other topics on this, but none of the solutions seem to work for me. Visual Studio is running old code in debug mode and release mode. If I go to the actual directory and launch the exe, it is the latest code. It is a XAML project.
Things I have tried:
1) Deleted bin and obj folders
2) Rebuilt solution
3) Cleaned solution
4) Made sure the project is set to build in Configuration Manager
Update: I tried adding a new configuration in Configuration Manager. The path is totally different, and it still running the old code. The exe built with the new config is the right code when I launch it manually, but it seems like visual studio is running a cached version of the exe.
Another gotcha I see a lot - be careful with shortcuts. If you are opening the solution via Recent Projects or another shortcut, try opening it via File -> Open or clicking on the solution file itself instead. I see a lot of developers looking at old code or the wrong branch because of this.
Can also try changing the assembly version number. Every once in awhile that will somehow make a difference.
I am not sure what exactly helped, but one thing is certain:
i marked .js file properties "Build action" as "Compile".
Tryed to deploy (got an error of course), and changed it back to "Content".
Rebuild, deploy, run debugger and FINALY it works on my current code.
The Error is back on my "new old" code
What i do is:
click "Continue", go to opened IE window with my page\site, press CTRL + F5,
and what i see?
My new current code inside VS debugger...
Error is gone
I created 2 instances of same project to apply different changes. So when I open project1 and debug class1, everything is smooth, I can have my breakpoints hit all other debugging features.
When I open project2 and close project1, I try to do same debugging on class1(some lines of the code is different), I get warning that
"the breakpoint will currently not hit. a copy of class1.cs was found in project1.dal.dll, but the current source code is the different from ther version"
When I close the VS completely and reopen the projects or If I clear the Temporary ASP.NET Files, Problem is getting resolved. But it happens everytime for me. so my questions are;
1) I wonder why does it happen and how can I resolve it without closing VS or clearing cache files?
2) I know the option called "Uncheck Require source files to exactly match the original version".. Is it safe to do it? or is there any side affects or disadvantages
It is impossible to debug your code in that way - you are creating different symbols for each build so when you debug one version, the other is not compatible with the previous one.
To make the long story short - you cannot debug one version of code when symbols from another version are loaded.
More info: Fixing "The breakpoint will not currently be hit. No symbols have been loaded for this document."
EDIT:
Check this link also: What is the "Temporary ASP.NET Files" folder for?
I am using Visual Studio 2012 and it was working all fine until I started observing some funny behavior. When I open my code it shows red Underlines which we usually see when there is an error in our code. Surprisingly, the code compiles all fine. I have made following observations that are not normal at all.
Red underlines in the code
While cleaning or building the solution no error.
Red underlines go away for some time after I build/clean the solution, but they come back eventually.
Because of this, my IntelliSense stopped working.
I can not right click on any component and go to its definition.
Any ideas?
Visual Studio 2017, Visual Studio 2019, Visual Studio 2022:
Closing Visual Studio and removing the .vs folder located in the solution directory worked for my C# projects.
This folder has a hidden attribute. You may need to change View settings to show hidden files in File Explorer.
Delete the contents of the temporary ASP.NET folder and then rebuild. It'll either be in your user folder (for IIS Express - \AppData\Local\Temp\Temporary ASP.NET Files) or the Windows directory (for IIS - C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Paths are off the top of my head and may not be correct
For me, this issue got fixed when I unloaded and reloaded the project again.
I had this issue and it was related to ReSharper.
Solution steps for me:
Disable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Suspend Now
Build Solution
(Ctrl + Shift + B)
Re-enable ReSharper
VisualStudio\Tools\Options\ReSharper Ultimate\General\Resume Now
Just had this problem while working with a solution created in Visual Studio 2012 but running in 2013. I closed Visual Studio, deleted all \bin and \obj directories and the problem was gone.
I had this problem after resolving some conflicts from Subversion (SVN). The solution has several projects in it and I resolved some conflicts in a few different projects. I did a menu Build → Clean Solution followed by a men Build → Rebuild Solution and everything was good again.
Do you have any plugins installed, like ReSharper? I had an issues with a bad plugin.
Try running Visual Studio in safe mode, to prevent plugins from running.
devenv /Safemode
If you are using ReSharper like me, you may delete ReSharper cache following by this link: Configure Caches
To specify the location for caches:
Open the Environment → General page of ReSharper options.
Use the Save solution caches in to select the location for cache files:
User local settings folder to store them in the following directory: %LOCALAPPDATA%\JetBrains\Transient
4.System TEMP folder to store them in the following directory: %TEMP%\ReSharperCache
Solution folder to store them in the root folder of the current solution
Custom folder to choose a custom location for ReSharper cache files.
Click Save to apply the modifications and let ReSharper choose where to save them, or save the modifications to a specific settings layer using the Save To drop-down list. For more information, see managing and sharing ReSharper settings.
Reopen your solution for the changes to take effect.
What works for me is deleting the IntelliSense indexfile.
The IntelliSense-file is in the same directory as you solution.
It's filename is SolutionName.sdf
Just delete this file, open you solution again, and IntelliSense will start rebuilding its indexfile. After that the problem will be gone.
In Visual Studio 2013 I solved this problem by deleting all of my obj and bin folders across all projects. The issue was probably due to solution configurations that I had deleted, but I hadn't been cleaned up properly, as doing a menu Build → Clean Solution doesn't remove the old outputs from the obj and bin folders.
This worked for me in Visual Studio Enterprise 2017:
Navigate to Tools > Options > Text Editor > JavaSCript/TypeScript > Linting > General
deselect "Enable ESLint"
I've run into this as well and was able to return Visual Studio to its normal state by doing the following -
Identify the project where the red lined code comes from
Remove the "red line" project from the references where it is being used (ProjectName\References - right click, add references, and uncheck the "red line" project)
Build (you should get errors now)
Readd the project reference that was just removed
Build again
The red lines should be removed and the project should build!
Steps that work
Open the solution and do a rebuild all
Close the solution
Open solution and do a clean
Close solution
Open solution and do a rebuild all
Close and then open the solution. It should be good. This works for me every time
Be careful deleting some of these settings files as you will lose saved debug settings, etc. And it may do more damage than you realize.
I have found recently it is easy to solve this by switching from Debug to Release in the dropdown to left of the Play Button. Then switching back from Release to Debug.
I had the same problem with lots of red lines in several *cpp source files. Though the code compiled perfectly. None of the other solutions worked for me.
Changing the order of #include lines of a *.cpp-file could make the red lines disappear - and reappear with the restored order.
Then I noticed a header file was included twice in a single *.cpp file. I removed the second one and - everything was fine.
Including a header file twice in the same *.cpp file seems to be no problem to the compiler but to the IntelliSense part.
Simply refresh the project/solution. It will get resolved.
I ran into this problem with the latest Visual Studio 2017.
Also the debug version of my program was running painfully slow.
I deleted the Solution file .sln and created a new one.
I had a similar problem when I was seeing lot of red squiggles in a couple of files. I tried all answers proposed previously, but nothing seemed to work.
The moment I started browsing through the classes, structures in other files for which complaining files had references, the problem disappeared. It seemed IntelliSense was not able to resolve dependencies on its own for some reason.
For me, I had at one time enabled fusion logging to debug some assembly dependency errors (fuslogvw from a CMD prompt). That was months ago and I had been experiencing much slower build times (5-7 minutes) since then.
I had also forgotten entirely that I had left them enabled. These logs were my bottleneck and disabling them has made iterating much faster.
In my case with Visual Studio 2017, I have many "red lines" shown below all symbols defined in a third-party library, but my project can actually build without problems. I have tried all suggested solutions (like delete the .VS folder, restart Visual Studio, etc.), but none of them working.
Finally, I fixed it and this is how: I open my application project's property page, then go to C/C++ → General → Additional Include Directories, which is the place I put all needed third-party library header paths.
I delete all the path (but save them somewhere), click "Ok" to confirm. Then I come back to the same setting, paste those paths back, click "Ok" to confirm, and then all those "red lines" disappear.
I have VS2019 with ReSharper, and ran into this issue.
What worked for me was:
Go to the ReSharper >> Options menu
Go to the General tab (should be the default)
Press the "Clear caches" button
Close all instances of Visual Studio (2019)
Restart Visual Studio
Using VS2022 without Resharper when this problem occurred, tried several things, this did help me in the end:
Close Visual Studio
Delete folder .vs in the Solution folder
Go to folder %USERPROFILE%\AppData\Roaming\Microsoft\VisualStudio\
Delete all folders whose names start with 17.
Reopen Visual Studio
More specific subfolders could exist that might be enough to delete, but I had no issues after deleting all of it. AFAIK these only contains user session data, temporary files and/or cache files that can be downloaded again or recreated as needed.
Found this solution:
Close Visual Studio (ensure devenv.exe is not present in the Task Manager).
Delete the %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\xx\ComponentModelCache directory.
Restart Visual Studio.
I have had this problem for months and have finally fixed it. Closing Visual Studio and removing the .vs folder located in the solution directory did not work for me.
There was an assemblyIdentity tag in the web.config file which was referencing a library that was not in my references folder. I removed this tag, cleaned, closed and reopened, and the problem was fixed.
Check each of the assemblyIdentity tags in your web.config file and check them against the references folder in solution explorer
Remove any assemblyIdentity tags, including the parent dependentAssembly tag for any which aren't listed in your references folder.
Clean the solution
Close and reopen the solution
Deleting .vs folder did the trick for me.
for me this works:-
Open the Command Palette ctrl+⇧+p
Then type: reload Window.
Deleting all the folders which start with "asp.xxx" worked for me. You can reach these folders by:
(C:\Windows\Microsoft.Net\Framework\vx.xx\Temporary ASP.NET Files)
Hover over the word that has the red underline squibble. A mini dialog box will appear. Click on 'Quick fix' and then click on 'Disable error squibble'.
I have set an output folder for my .dll project though the Project Properties, which I call "Output".
The problem is, from an empty Output folder, the first time I Build the project, it's fine. The second time, I get the following error:
Error 328 Unable to copy file "obj\Release\MyLibrary.dll" to
"......\Output\Release\MyLibrary.dll". The process cannot access the
file '......\Output\Release\MyLibrary.dll' because it is being used
by another process.
The "another process" is the vshost.exe from Visual Studio. Since it keeps acessing MyLibrary.dll, it can't be deleted or replaced, thus why the error. This keeps the MyLibrary.dll on the Output folder not updated. However I have other .dll projects in my solution in which this does'nt happen.
The solution I have used so far to update it is to close the VS (thus closing vshost.exe), then run a .bat file which deletes the file Output\Release\MyLibrary.dll, then open the VS again and Rebuild it's project.
I know little of what exactly vshost.exe does, so I have no idea from where to start to clear this problem from the root. I don't know why this happens to a specific .dll. I appreciate any idea that helps me investigate why this happens.
vshost.exe is the Visual Studio Hosting process. It is a custom CLR host that loads your EXE and makes debugging easier. You can turn it off, that has very few side-effects. Project + Properties, Debugging tab, untick the "Enable the Visual Studio hosting process" option.
You are more likely to find the real problem in your program now. With the most common issue that your program doesn't quit when you ask it to. You will still get a build error, you'll now see your own EXE fingered as the one that keeps a lock on the DLL. You will also see it back in the Task Manager's Process tab. Which also allows you to kill it.
It isn't that clear to me how programmers recreate this problem. Pressing Ctrl+F5 instead of F5 certainly will do this, always press F5 to immediately attach the debugger when you start the program. Using Debugger + Stop Debugging will now reliable stop the program. You can otherwise use Tools + Attach to Process to get a debugger attached again later to find out what your program is doing.
Anti-malware is a common scourge worth mentioning, they get way too excited when they see an executable file appear from nowhere. If you use Avast then just uninstall it completely, it is quite incompatible with VS.