none
How to stop build on error detected with Visual Studio 2005 ? RRS feed

  • Question

  • Hi,

    I have a project made of many files and would like the build to stop when an error is detected.

    It currently compiles all the files with or whitout errors. How can I specify the build to stop on error detected?

     

    Thank You.

     

    Charles

    Tuesday, February 5, 2008 12:35 AM

All replies

  • Bump an anunswered febuary thread
    Friday, June 13, 2008 8:28 AM
  • You can add the "Compile" command to the toolbar. This gives you the ability to compile one source file at a time.

    Right-click on toolbar, Customize, Commands tab, Build category, drag the Compile icon to your toolbar.

    • Proposed as answer by Brian Muth Friday, June 13, 2008 4:45 PM
    Friday, June 13, 2008 4:44 PM
  • This doesn't answer the question.  The requested feature is for the entire build to stop when the first error is detected.

    The requested feature would save the time of the developers and builders of the project.  For example, let's say it takes 30 minutes to build a large project.  If an error occurs 2 minutes into the build (for example an automated integration build), then 28 minutes of human time is wasted before the build problem will be addressed.  Sometimes the offending code might be a checkin from a different developer.

    Once the problem is found, of course the "compile" command is invaluable.  But anyone asking how to stop the entire build after the first error probably already knows about the "compile" command.

    Thank you.
    Friday, February 6, 2009 4:56 PM
  • I agree this is a really annoying default and seems to come from the inherent use of MSBuild, and it is still there in VS2008! How disappointing. 

    I think the design of MSBuild is limiting us here. Then that is where the issue should be fixed then everything would work sensibly and save lots of time, even for a stand-alone developer. I remember in the pre-MSBuild days there was an option (I used C++ then) to stop on first error and I think it was default. What happened?

    Did anyone find a workaround for this? Perhaps a special MSBuild task that can stop it's chilren from building when the first fails? Needs project dependencies to be considered too because there could be multiple threads building at the same time.
    Wednesday, April 8, 2009 1:29 PM
  • hi, when building your app and if you see a there is a shortcut to stop the build (CTR + the break key (on most keybords it is the same key as the PAUSE key))
    i Have added a extra button to my toolbar that has the same effect.

    The button can be found by right kliking on the toolbar->Costumize...-> in the TAB Commands select the categorie Build and there you find a button "cancel"

    dragg it to a toolbar to add it.

    now when building you can klick on it and the build will stop.


    Hope that helps,...




    GRZ A.
    • Proposed as answer by azertykk Wednesday, April 8, 2009 7:13 PM
    Wednesday, April 8, 2009 2:39 PM
  • Thanks for the suggestion. When I notice the build is running wild after the first error I hit CTRL+BREAK to stop the build and if I'm luckz and VS doesn't hang itself it'll stop. What I am after is feature request so I'll drop that in MS Connect and hope it appears in VS 2010.
    Friday, April 10, 2009 6:52 PM
  • I remember in the pre-MSBuild days there was an option (I used C++ then) to stop on first error and I think it was default. What happened?

    If that option ever existed it was never the default and I doubt that the option did exist ever. I have used VC since version 1 and I used the predecessor, the Microsoft C compiler before it was renamed to Visual C++. I have never seen that option; I am not saying it did not exist but I doubt that it did.

    If I work on a project in which I expect many errors from many files, I will compile one at a time; that is, do just a compile, not a build. If I do a build and I get many errors from many files, then I do the same thing; I fix errors in one file at a time and compile one at a time and repeat as necessary. I know of no other way to deal with the situation in which there are many errors from many files.
    Sam Hobbs; see my SimpleSamples.Info
    Sunday, April 12, 2009 2:00 AM
  • a modified code from http://www.ehow.com/how_5025041_automatically-visual-studio-build-error.html by eric m,
    press Alt-F11 -> MyMacros -> EnvironmentEvents -> paste it before "End Module"

    Private Sub OutputWindowEvents_OnPaneUpdated(ByVal pPane As OutputWindowPane) Handles OutputWindowEvents.PaneUpdated
    If Not (pPane.Name = "Build") Then Exit Sub
    
    pPane.TextDocument.Selection.SelectAll()
    Dim Context As String = pPane.TextDocument.Selection.Text
    pPane.TextDocument.Selection.EndOfDocument()
    
    Dim found As Integer = Context.IndexOf(": error ")
    Dim foundFatal As Integer = Context.IndexOf(": fatal error")
    
    If found > 0 Or foundFatal > 0 Then
    DTE.ExecuteCommand("Build.Cancel")
    End If
    
    End Sub 
    • Proposed as answer by Code Chief Tuesday, July 14, 2009 11:02 AM
    Sunday, July 12, 2009 1:14 PM
  • Simple Samples, thanks for the correction but that doesn't help with the solution. I too have used a lot of different compilers over the years from different companies, for many different languages and complexity levels (assembler - C - C++ - C#). I may not remember all the settings exactly but I never encountered such an annoying behaviour as a "run-away build", to give it a name.

    Trying to select and individual files is cumbersome and is not feasible when making changes across multiple projects, e.g. refactoring, building or extending object models.

    CTRL+BREAK was known from the start but the responsiveness of the VS UI is terrible during a build of a real meaty solution.

    Sonicth found the solution. It's the best because it occurs immediately, is persisted with the user in their macros directory, is fully automatic and should be a supported way to extend VS behaviour.

    I think that little nugget should go on a VS development best practice list.

    Tuesday, July 14, 2009 11:02 AM
  • Thanks sonicth for the solution, that's a nice workaround.

    I used the original code from the link you provided (below plus a couple of comments). Was there a reason you had to extend it with text comparison rather than the Success flag? Initial tests show it works as-is with VS2008 SP1.


    ' Handles the BuildProjConfigDone event to stop building after first project build fails.

    Private Sub BuildEvents_OnBuildProjConfigDone(ByVal Project As String, ByVal ProjectConfig As String, ByVal Platform As String, ByVal SolutionConfig As String, ByVal Success As Boolean) Handles BuildEvents.OnBuildProjConfigDone

    ' Automatically stop building on first error

    If Success = False Then

    DTE.ExecuteCommand("Build.Cancel")

    End If

    End Sub

    Tuesday, July 14, 2009 11:05 AM
  • Simple Samples, thanks for the correction but that doesn't help with the solution.

    It helps better than sending a person on a search for something that does not exist.
    Sam Hobbs; see my SimpleSamples.Info
    Saturday, July 18, 2009 9:01 PM
  • The title of the thread and desired solution was "How to stop build on error detected with Visual Studio 2005".
    Sunday, July 19, 2009 1:15 PM
  • You can add the "Compile" command to the toolbar. This gives you the ability to compile one source file at a time.

    Right-click on toolbar, Customize, Commands tab, Build category, drag the Compile icon to your toolbar.


    though technically correct, i am quite sure most people have more than one source file in their rather large business solution.

    this is not a solution for say a project with 100's or perhaps 1000's of source files that can take hours to build.  no one will sit there manually clicking away.

    Micky D
    Tuesday, March 16, 2010 1:34 AM
  • this is not a solution for say a project with 100's or perhaps 1000's of source files that can take hours to build.  no one will sit there manually clicking away.

    The solution for a project with 100's or perhaps 1000's of source files is multiple projects.

    I have not worked with projects that big, but if I did, I think it would be especially important to compile one file at a time. Of course, if I could, I would make the project multiple projects. In the relatively small projects I have worked with, it was distracting and wasteful to compile all files when I got errors. It was easier for me to fix errors for just one file at a time. In a project with 100 source files, chances are, we just have to fix the errors in one file and then most errors for most files go away. So we don't have to click and click and click 100 times.

    Sam Hobbs; see my SimpleSamples.Info
    Tuesday, March 16, 2010 1:48 AM
  • Correction: I have worked with huge projects, but not when the computer was as powerful as they are now. In the days in which the projects I worked with were huge, it would be considered foolish to compile every source file every time that fixes were applied to a file in an application; that is, the equivalent of an application. What's the purpose of doing that, other than wasting processing time that others could use?

    Of course, PCs are different; one machine does not support all development for a large staff of developers. There was a time when one computer would support all development from 50 programmers. Developers now have no problem casually compiling 100 source files all at once.

    Yes, it is foolish to "manually" compile every file to build a large project. That is not the purpose of a compile button. I guess I should have said that at the beginning; I apologize for ranting if it was not relevant.

    Sam Hobbs; see my SimpleSamples.Info
    Tuesday, March 16, 2010 2:00 AM
  • this is not a solution for say a project with 100's or perhaps 1000's of source files that can take hours to build.  no one will sit there manually clicking away.

    The solution for a project with 100's or perhaps 1000's of source files is multiple projects.

    that only does not fix the issue but is also irrelevant . not to mention slightly insulting .

    Micky D
    Tuesday, March 16, 2010 2:05 AM
  • I remember in the pre-MSBuild days there was an option (I used C++ then) to stop on first error and I think it was default. What happened?

    you are absolutely right, i just did a test with VC 6.

    Solution contains 2 projects , each with a number of files. if a compile error occurs during compiling of the first project it does not compile the second - which is good.

    Unlike Visual Studio 2005, 2008 which continues to build each consecutive project which is just plain silly.


    Micky D
    Tuesday, March 16, 2010 2:58 AM
  • now when building you can klick on it and the build will stop.


    Hope that helps,...




    GRZ A.
    you cant be serious? and why is this marked as an answer?

    Micky D
    Tuesday, March 16, 2010 2:59 AM
  • I remember in the pre-MSBuild days there was an option (I used C++ then) to stop on first error and I think it was default. What happened?

    If that option ever existed it was never the default and I doubt that the option did exist ever. I have used VC since version 1 and I used the predecessor, the Microsoft C compiler before it was renamed to Visual C++. I have never seen that option; I am not saying it did not exist but I doubt that it did.

    If I work on a project in which I expect many errors from many files, I will compile one at a time; that is, do just a compile, not a build. If I do a build and I get many errors from many files, then I do the same thing; I fix errors in one file at a time and compile one at a time and repeat as necessary. I know of no other way to deal with the situation in which there are many errors from many files.
    Sam Hobbs; see my SimpleSamples.Info

    really? i just did a test with VC 6 and it is NOT the case and it is the default behavior .

    Solution contains 2 projects , each with a number of files. if a compile error occurs during compiling of the first project it does not compile the second - which is good.


    begin of rebuild all with error in  first project (result is EXPECTED) -----------------------------------------


    Deleting intermediate files and output files for project 'MyLib - Win32 Debug'.
    Deleting intermediate files and output files for project 'Test - Win32 Debug'.
    --------------------Configuration: MyLib - Win32 Debug--------------------
    Compiling...
    StdAfx.cpp
    Compiling...
    test1.cpp
    C:\Program Files\Microsoft Visual Studio\MyProjects\Test\MyLib\test1.cpp(7) : fatal error C1004: unexpected end of file found
    test2.cpp
    Generating Code...
    Error executing cl.exe.

    Test.exe - 1 error(s), 0 warning(s)

    -------------------------------------------------------------------
    begin of rebuild all after fixing error in first project (result is EXPECTED) --------------------------

    Deleting intermediate files and output files for project 'MyLib - Win32 Debug'.
    Deleting intermediate files and output files for project 'Test - Win32 Debug'.
    --------------------Configuration: MyLib - Win32 Debug--------------------
    Compiling...
    StdAfx.cpp
    Compiling...
    test1.cpp
    test2.cpp
    Generating Code...
    Creating library...
    --------------------Configuration: Test - Win32 Debug--------------------
    Compiling resources...
    Compiling...
    StdAfx.cpp
    Compiling...
    Test.cpp
    C:\Program Files\Microsoft Visual Studio\MyProjects\Test\Test.cpp(23) : error C2143: syntax error : missing ';' before 'const'
    C:\Program Files\Microsoft Visual Studio\MyProjects\Test\Test.cpp(23) : error C2501: 'kpokpokpk' : missing storage-class or type specifiers
    MainFrm.cpp
    TestDoc.cpp
    TestView.cpp
    Generating Code...
    Error executing cl.exe.

    Test.exe - 2 error(s), 0 warning(s)


    -----------------------------------------------------------
    Now if i did this in vs2005 or 2008 it would build both projects regardless.  Unlike Visual Studio 2005, 2008 which continues to build each consecutive project which is just plain silly.

    I have been using Microsoft c/c++ since the V5 DOS version, though I cant claim for certainty what V5 did, I suspect this behavior was not native to VC6.

    like the other poster said, it wasn't until .NET was introduced did c++ get upset.


    Micky D
    Tuesday, March 16, 2010 3:06 AM
  •  It was easier for me to fix errors for just one file at a time. In a project with 100 source files, chances are, we just have to fix the errors in one file and then most errors for most files go away. So we don't have to click and click and click 100 times.

    Sam Hobbs; see my SimpleSamples.Info
    hmmm anyone with lots of experience in c++ knows that sometimes the result of 1000 errors is caused by merely 1 faultunfortunately of the 1000 errors the majority are irrelevant because they are all in other projects which depend on the former.

    if VS2005 and 2008 behaved as its predecessors once did we would not see this sort of pollution.

    Micky D
    Tuesday, March 16, 2010 3:11 AM
  • agreed.

    the 'solutions' to the issue in this thread are perhaps questionable and am unclear why there are marked as answer indicators

    the last MS c++ that did the job right that I know of is VC++ 6.
    Micky D
    Tuesday, March 16, 2010 3:24 AM
  • Quite right. It's a ludicrous change in behaviour by Microsoft. Many of the "answers" miss the point completely. With a large project, I'm sure many people do the same thing as me: set it compiling and go and do something else in the meantime. No one sits there for half an hour watching VS output scroll by, surely? If you see that VS is still compiling, you assume there's no error. There's nothing more annoying than finding that a project at the bottom of the pile failed half an hour ago. And to discover that, you have to wade through reams of useless output. If project B depends on project A, and project A fails, why bother continuing with project B?

    Absolutely insane. 


    Thursday, November 7, 2013 11:36 AM