In Visual Studio 2010, if you hit f5 and get a compile error, a dialog pops up asking if you want to run with the last successful compiled version. I never want to do this. Is there a way I can make it not show this dialog, and instead take me to the first compile error? (Like Delphi used to do.)
Go to Tools, Options, Build and Run, and change On run, when build or deployment errors occur.
Related
I am having an issue with Visual Studio 2015 and Xamarin.
As I am working and hit Build/Rebuild/Deploy, I get stuck in this loop where I have to hit the button in the Build menu 3+ times before it successfully takes.
When it fails, it does not attempt to build. It just immediately says that the Build failed in the bottom-most toolbar (where it says Ready in the left-hand corner).
There is no output.
Then, after a few attempts, the Output window gains focus where it says --- Build Started --- and proceeds as normal without issue.
Has anyone experienced this? Any solution?
It is not an issue with MSBuild project output Verbosity, again there simply is no output.
I will mention I am also using ReSharper, and latest version of VS2015, Xamarin, etc.
I would clean the Debug/bin and Debug/obj folder for any subsequent build.
I am using Visual Studio 2013. I use a single start up project. There are more than 8 projects in the solution. Here is what I used to do when I was on Visual Studio 2010;
I would Build the solution. Then run it from its .exe file in /bin/Debug, then on Visual Studio, I would Attach to Process and it would start debugging and it would always hit the breakpoints as long as the source code and the .exe are not different.
This is the same thing that I do on Visual Studio 2013. I put the breakpoints in a file in my startup project. I build the solution (it says it successfully builded on the output window), or I Start Without Debugging, then attach to process, it says "The breakpoint will not currently be hit. The source code is different from the original version" Then I stop debugging, and without building again, I run the .exe again, attach it, then the breakpoints start hitting. Why do I have to close my .exe and then start it again? I use attach to process a lot and this 'must do twice to hit' is really annoying. I haven't change any configuration or anything. What am I doing wrong? I swear I don't change the source code. Not even a single space. It says "Build succeeded" when I attach it.
I have a similar issue. (on a webproject)
my temp solution:
right click the web project
Select Property Pages
Under Build --> Change the Target Framework to something else than the one selected (Apply the new framework)
Then Change back to your desired framework and Debug
I've got VS2010, nunit, and resharper. I've written a bunch of tests and when I debug those tests I can set breakpoints within the test code itself and those are hit, but no breakpoints within my solution itself are hit (the actual code that the test code is calling).
Is there a way to hit the breakpoints throughout my solution while debugging a test?
Have you tried Tools->Options->Debugging->Enable Just My Code
This may happen sometimes if you have build errors and debugger is executing binaries from previous build (Launch old version). This option can be disabled in Visual Studio:
Tools -> Options -> Projects and Solutions -> Build And Run
On Run, when build or deployment errors occur
The message box is not displayed and the newly built version of the
application is not started. This option is set when you select Do not
show this dialog again in the message box, and then click Yes.
When working in VS, the error messages in the bottom panel are compiler errors and warnings, right? Does this mean the app is being compiled all the time? I would expect those to appear only when trying to run the app.
This is probably a silly question, but I cannot find the answer.
Visual Studio continually parses the source code; this allows it to preemptively report some errors before you actually compile the source.
This is, of course, dependent upon which language you are using. C++ didn't get preemptive error reporting until Visual Studio 2010.
Visual Studio doesn't natively continuously compile code.
However, I just downloaded the 14 day trial of this little app called .Net Demon that's a plugin for Visual Studio. It costs $30, but definitely a nifty tool if you've got large solutions with many projects.
http://www.red-gate.com/products/dotnet-development/dotnet-demon/
I'll probably end up breaking down and buying it, it's pretty slick.
Each programming language is different (each provides a Visual Studio 'language service' specific to that language that provides the feedback), but for the most part, yes, it is being compiled over and over. In F#, for example, the compiler is divided into a few stages, main ones being lexer/parser, typechecker, and code generator, and the lexer/parser/typechecker are running inside VS, and every time you type a character into a file, that file is re-run through those stages of the compiler.
When you compile an application there might be errors and warnings which will be shown at the errors window. When you run the application errors will no longer be shown in Visual Studio but depending on how your application is organized it will either crash or handle them gracefully. Also notice that if you try to run the application with F5 or Ctrl+F5 Visual Studio will try to compile it first and if there are compile-time errors and warnings they will be shown.
In the past week or so, I've noticed that Visual Studio 2010 is not recompiling code unless I force it to. This is a C# 4.0 project with WPF. I hit F5, which seems like it used rebuild, if the code had changed, and then launch the app. Instead, it now says in the bottom left status bar "Build Successful" and launches the application. It doesn't actually rebuild the app, though. I can tell because:
even if I make a large number of changes, it "compiles" very quickly and
if I try to set a breakpoint, it gives the warning that the code has changed and doesn't
set the breakpoint.
This happens regardless of whether there are errors in the code or not, so I don't believe it's the thing where it launches an older version if the build fails.
If I instead select from the menu to rebuild the project, it then works. This kind of impedes my usual workflow, however. I semi-frequently forget to do this, and then spend 10 minutes trying to figure out what the hell is wrong with my changes. Even worse, sometimes there are build errors that I don't notice right away.
Pressing F6 to "rebuild" the solution does not do anything either. What settings might I have mucked with that would cause this behavior?
Gah, I figured this out. It was naturally something stupid I did when messing around with build settings after a too-late night. Here are the things to check:
Tools >> Options >> Project and Solution >> Build and Run >> Check that "On run, when projects are out of date" is set to "Always build" or "Prompt to build"
Build >> Configuration Manager >> Check that "Build" is checked for all of the projects you want to build for each of the configurations you need to use.
Also if multiple projects in solution, check configuration manager.
If you have some projects "Any CPU" and some "x86", will be builded only projects of same arhitecture.
Same with "Debug" and "Realese" config.
Had similar issue in 2020 with VS 2019 (Community Edition) and WPF project not being rebuilt (deemed as "up-to-date") even though the referenced project was rebuilt. The above advice (Tools->Options and Configuration Manager) is met in many places, though didn't work for me.
Eventually changing .csproj file and adding the following line (under ProertyGroup) worked for me:
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>