In my solution, I have a Visual C++ project which uses
Platform Toolset = Visual Studio 2013 (v120)
which I am opening in Visual Studio 2019.
If I edit the Project Properties > Configuration Properties > Debugging > Command arguments to something , and do OK it goes well, as if I open this dialog again is everything OK.
But when I run the application, the Command Arguments got cleared, for the specified configuration, as the same odd behavior happens both in Release and Debug Configurations. This way I can not use VS interface to parameterize the command input.
The moment I hit the Play button, the parameterization has disappeared: 🙁
Help, please.
UPDATE:
It seems to be an extension causing the strange behavior. I disabled every extension I could, and the behavior is not happening now. When I have time, I will try to cherry pick what extension is annoying me and give more updates.
UPDATE 2:
I just enabled extensions by blocks of a few alphabetically and ended up with all of them being enabled, and seen VS is just behaving well. I am believing the fact of disabling some extension has put things back on track.
I just uninstalled an extension named "Smart Command Line Arguments" and now things seem to work fine.
May be I was using wrongly, I don't know.
Now I will be continuing my work, and if I don't find any problems, I will accept my present answer.
It happened to me today again. I did some disk cleaning some days ago, I may have touched something in Visual Studio 2019.
Now, I was getting the same problem. This time, after seeing VS having several times this bad behavior, I tried to change the command line arguments, DID NOT start debugging, then I restarted VS, started Debugging again and now it seems to do what is supposed, not to clear my command line arguments customization.
UPDATE: this is happening again. It happens when it is not the first time I click "Start Debugging" after starting Visual Studio. So this implies I will have to restart VS almost every time I want to start debugging, for not getting the command line arguments cleared. ☹
Related
Visual Studio Intellisense is bugging out and only works on my current startup project.
I'm in the process of building a multi-project solution and as of earlier today Visual Studio decided that Intellisense would stop colour coding and providing information about code that I hover over with my mouse.
this is happening in all files within the solution apart from the single one in my current Startup Project.
I'm unsure whether the fact that that file is inside the startup project is important or not or what at all caused the bug to begin the first place.
I've been searching around for a while and tried just about every 'solution' that has come up.
I've changed the relevant settings off and on again.
I've deleted the dynamic .suo file in the hidden .vs folder.
I've reopened the files, visual studio, updated, made sure intellisense wasn't doing something in the background.
Apparently this bug can be caused by a corrupt .ncb file that lives in the solution directories, but I've failed to locate a file with that extension anywhere.
I'm also not using any extensions or such that mess with Intellisense's operation.
Are there any other possible things to try (hopefully not reinstalling) or just continue writing code in black and white?
Intellisense working:
Intellisense not working:
Maybe you can check your intellisense setting in Tools > Options > Text Editor > C/C++:
This is a document about intellisense in C++. Hope it can help you.
If it doesn't work you can try to Reset all setting in Tools > Import and export settings. Or try to repair visual studio in visual studio installer.
If the above methods don't work, maybe you can only try to reinstalle visual studio.
Frequently I want to change code when the project is running, but am disallowed from doing this because Edit and Continue is enabled.
I assume this is some kind of protective measure, because the changes I make won't apply to the current execution, but I am fine with that. I would like to make them, and then click 'apply' somewhere to make the build update. Is this possible? (It used to be in previous versions of Visual Studio)
Opening a second instance of Visual Studio, and opening the code file there will allow this to be done.
I have seen the following questions and tried all of their answers:
Visual Studio Go to Definition (F12) opens Object Browser instead of Code View
How can I turn "Object Browser" to "Metadata" for "Go to definition" in Visual Studio 2010?
Namely that I have tried:
Cleaning the project and deleting all generated project files
Resetting all of the keyboard mappings
The difference in this question from the previous listed is the following:
It is a C++ project, not c#, there are no references and no .NET version.
I have not installed nor do I use the ReSharper program.
I have tried checking out the same code and solution in a separate directory, and the problem no longer occurs (but still occurs in the original after a clean checkout)
This started today, and I am unaware of an event that could have caused it. I have not installed any new plugins or similar. The only thing that has happened recently was that yesterday I installed some NUNIT references into a C# project that is in the same solution.
Since the other posts listed above did not list explicit details about the problem, this is a detailed description of what is occurring:
I try to go to definition on an object (or go to declaration), with either F12 or the right-click menu:
Instead of going to the source of this (ie the HeartBeat class) it will show in the symbol search a list of possibilities:
All of these references open the object browser window instead of going to the source:
How can I revert the behavior of visual studio to normal?
As the OP mentioned, /resetuserdata will definitely bring your Visual Studio back to normal as follows:
devenv.exe /resetuserdata
although this is not the fundamental solution.
This kind of weird situation can occur especially when you run multiple Visual Studio at the same time, and you changed a few configurations only on one of them.
That's because Visual Studio tries to share the same .vssettings and the file is over-written every time it exits, to keep .vssettings to have the newest configuration sets you made at all times - the definition of the newest configuration is the one the last Visual Studio that you closed has.
Therefore, the configuration change that you think you've made might not be the one your Visual Studio is running on.
To prevent this from happening, you could make your .vssettings Read-Only.
Then every time you close it, your VS will complain about it, but you can keep your customized configuration safe. (Which, I agree, is sort of ugly though)
I am using Visual Studio Premium 2013 Update 2 on a freshly installed (fast) machine with Windows 8.1 Update. Everything is running smoothly, only one thing bugs me:
Problem
When I debug a native C++ project (debug build) by going from line to line with F10 ("step over") it takes 1-2 seconds to go to the next line when I press the F10 key.
What I tried
I looked at several other questions related to slow debugging and made sure that neither of the following is not the reason in my case:
Everything is local (app and all data), no network shares involved
Disabling the Microsoft symbol server did not help
I only have a single breakpoint
Using the menu/toolbar instead of the keyboard does not make any difference
In the default configuration "edit and continue" is enabled, but apparently not for native code:
When I disabled "edit and continue" completely, F10 stepping became much faster (0.5-1 s). The speed is tolerable now. I had to restart Visual Studio after I changed the configuration to this:
We have a few C++ solutions and we run some build scripts using batch files that call msbuild.exe for each of the configurations in the solutions.
This had been working fine on 3 developer machines and one build machine, but then one of the projects started to hang when linking. This only happens on the newest machine which is a quad core, 2.8ghz I think. It runs on Windows Server 2003 and the others are on XP or Vista.
This happens consistently even if I change the order of builds in the bat file.
If I run the build from the IDE on that machine it does not hang.
Any ideas about what could possibly be causing this?
I am using Visual Studio 2008.
Edit:
I see now that when it is hung the following are running:
link.exe (2 instances) One with large memory usage and one with a small amount of memory usage.
vcbuild.exe
msbuild.exe
vcbuildhelper.exe
mspdbsrv.exe
Edit:
The exe file exists and so does the pdb file.
The exe file is locked by some process, and I can't delete it or move it. I can delete the pdb file though.
I also have the problem if I just use VCBuild.exe.
I decided to try debugging the 2 link.exe processes and the mspdbsrv.exe processes.
When I attached the debugger/MSdev IDE to them I got a message box saying that the application was deadlocked and/or that "all threads have exited".
I guess I will have to check for a service pack for that msdev install on that machine.
Edit:
In the debug.htm output file I get all sorts of stuff output after the link.exe command is generated.
However, for the release buildlog.htm the linke.exe line is the last line.
This is clearly a hang in the linker. Definitely a Microsoft bug.
I am now trying to figure out what the .rsp (linker response) file is.
When I issue:
link.exe #c:\\Release\RSP00000535202392.rsp /NOLOGO /ERRORREPORT:QUEUE
That is the last line in the release build log. The debug one has lots more information after that.
Reinstalling a different version of Visual Studio did not solve the problem.
I will open an issue/ticket with Microsoft. I will post an answer if I can.
Whole-program optimization (/GL and /LTCG) and /MP don't mix -- the linker hangs. I raised this on Connect.
The upshot is that it's a confirmed bug in VS2008; contact PSS if you want a hotfix; and the fix is included in VS2010.
If you can't wait that long, turn off /MP (slower compiles) or /LTCG (slower code).
Are you using xcopy in your scripts? This suggests wrapping xcopy with cmd /c " .. " as a solution.
If that wasn't it, I'd recommend to narrow things down by only letting one cpu work (i.e. removing /maxcpucount) This would rule out any form of race condition between compilation processes.
I had a similar problem, but with Visual Studio 2010.
This is a project that had worked fine on another computer, but just not my new one.
The symptoms described matched the original Visual Studio 2008 Issue.
I was able to resolve the issue by installing the Visual Studio 2010 Service Pack 1 (SP1)
http://www.microsoft.com/download/en/confirmation.aspx?id=23691
- or just go to microsoft and search for "Visual Studio 2010 Service Pack 1"
I had run my windows "check for updates" and had thought I had installed all service packs, but apparently, I had not installed any Visual Studio Service Packs.
After installing the VS2010 SP1, I no longer had this issue.
I confirmed that I had installed VS2010 and the Service Pack 1 on other older computer with the working project a while back.
You could try this: Open the build dialog via
Menu -> Tools -> Options -> Projects and Solutions -> Build and Run
Here you can set "MSBuild project build output verbosity" to
"Diagnostic". Maybe this will deliver more information on what is
going wrong.
In the same dialog you can set "Maximum number of parallel project
builds" to 1. Maybe this works around the link.exe "hang".
mspdbsrv.exe is used to combine all debug info into one pdb file. The VS2005 version of mspdbsrv.exe is buggy, it might be that the VS2005 version has some of the same issues. Killing it before building is making a difference for some people. We're going to add it to our builds as well since we're regularly suffering from unknown PDB errors.
Have you tried disabling incremental linking, or alternatively, always forcing a Rebuild All?