none
Build Complete Notification Sounds RRS feed

  • Question

  • I just upgraded to Visual Studio 2005 from VS6.0  and I cannot find any documentation for Visual Studio sounds schemes.  In VS6.0 I could have seperate sounds for "BuildComplete", "BuildError", and "BuildWarning".  In Visual Studio I can only create a sound for VS_BreakpointHit  Are any of the others available?
    Wednesday, January 4, 2006 10:45 PM

Answers

All replies

  • No. Sorry.

    If we were to bring them back, which ones would you want?

    Wednesday, January 4, 2006 11:15 PM
    Moderator
  • The three I mentioned in my post BuildComplete, BuildWarrning, and BuildError.  I found I didn't need notification for every warning or error durning the build, but an all done sound was very usefull.  Some sounds when doing a "Find in Files" would be nice as well.

     

    Claude Turner

    Thursday, January 5, 2006 2:46 PM
  •  Paul Harrington MSFT wrote:
    If we were to bring them back, which ones would you want?

    This seems a rather inefficient way to go about this -- asking developers one by one which features from a previous version they want in the new version.

    It also seems kinda dumb just from a programming point of view. If you create a capability to allow three or four events to be selected, why not generalize and expose a hundred events?

    So the answer is: I want all of them back, and I want Microsoft not to remove features between versions of the IDE.

    This seems to be characteristic of this release, at least from the standpoint of those of us developing for Windows CE... sorry, Pocket PC... sorry, Windows Mobile-based Pocket PC. Random useful features were dropped, such as CObject::Dump() from MFC. The argument that it "saves space" is vacuous since functions in the debug version of the DLL don't ship on the ROM.

    Deprecating functions like strstr() is another bizarre move.

    It's as if nobody working on this release of the compiler ever used the previous versions, and no legacy code was compiled during testing.

    But I digress. We want all the notification sounds back, thank you.

    Craig

    Tuesday, January 31, 2006 8:47 PM
  • It looked like there was an attempt to have them.  In my control panel I have no less than 4 "build failed" and "build succeeded" sounds.  I put sounds for all of them but still get nothing from vs2005 while my vs2003 does make noise.  The 4 categories are "Microsoft Development Environment", "MSDN Library - Visual Studio .NET 2003" (why here?) "Microsoft Developer", and "Microsoft Visual Studio Macros"
    Thursday, February 9, 2006 10:33 PM
  • Not only are the sounds missing, there isn't any documentation about this or any other "things we took out because we could".  I had to Google to find this thread - the VS2005 help search couldn't handle it.

    So, just for grins, can someone explain why the sounds were removed?

    Tuesday, February 14, 2006 10:13 PM
  • I am one more long-time Visual Studio customer who is more than a little annoyed that the 3 build sounds have been removed.  In my view, the "build succeeded" and "build failed" sounds are more valuable than the one that was retained, and more valuable than many other features.  Most of my development efforts (C++) are a tight edit and build cycle, often with many cycles per minute.  After hitting F7 to build, I generally turn my attention momentarily to other matters.  Without any effort on my part, the sound tells me instantly whether my edit was correct.  Without these sounds, I cannot know whether -- or when -- the build succeeded without carefully reading and parsing the output window.

    It really feels like "programmer abuse" for me to have to do that.  Would this feature be restored if it were classified as an "accessibility option"?
    Tuesday, February 21, 2006 6:49 PM
  • Here are three tips to avoid having to read and parse the (entire) output window:

    1. Look in the status bar. It says "Build succeeded" if there are no errors.

    2. Open the Error List tool window. If all is well, there will be no errors reported.

    3. The last line of the output window is a summary line indicating how many builds failed.

    Your request for the return of audio cues can be logged in the product feedback center.

    Jweisz, The audio cues were removed for performance reasons. Initializing the multimedia DLLs to play the sounds was costing several hundred milliseconds in some high priority performance scenarios (edit/build//debug cycle).

    Tuesday, February 21, 2006 10:53 PM
    Moderator
  • I'm grateful for your timely response.  Of course, I'm more than happy to pay the several hundred milliseconds.  Those that don't needn't enable this feature.

    Where do I find the "product feedback center"?  Can you submit this request for me?  Or can I point my feedback at this thread?
    Tuesday, February 21, 2006 11:51 PM
  •  Paul Harrington MSFT wrote:

    Here are three tips to avoid having to read and parse the (entire) output window:

    1. Look in the status bar. It says "Build succeeded" if there are no errors.

    2. Open the Error List tool window. If all is well, there will be no errors reported.

    3. The last line of the output window is a summary line indicating how many builds failed.

    Your request for the return of audio cues can be logged in the product feedback center.

    Jweisz, The audio cues were removed for performance reasons. Initializing the multimedia DLLs to play the sounds was costing several hundred milliseconds in some high priority performance scenarios (edit/build//debug cycle).

    How wonderfully condescending! Thank you! Unfortunately, this post misses the point. Most or all of these methods for seeing if a build succeeded exist in earlier builds of the IDE but  we still used the notification sounds. If this post had anything to do with the problem, one would have to ask why we bothered to use notification sounds in the previous versions.

    And again, the "performance" excuse is a lame one and shouldn't have been accepted when the feature was removed, let alone trotted out now to appease developers. A typical developer spends significantly more time editing and debugging than they do building. If this is not the case, that is, if builds are taking six hours per day and edit/debug is taking two hours per day, then the few hundred milliseconds lost in initializing some DLL is insignificant. If the opposite is the case, where 2 hours are spent building and 6 debugging and editing, then a few milliseconds of build time are similarly insignificant.

    Consider the worst case scenario where initializing the DLLs takes 1000 milliseconds -- way more than you said it would take -- and building the app takes 10 seconds -- a pretty small app. Say you spend one minute debugging and editing between builds. In an eight hour day you would build the app 405 times. A total of 6 minutes and 45 seconds would be wasted loading the multimedia DLL. Since the actual number was "several hundred milliseconds", the wasted time would actually be around half that.

    So what Microsoft is saying is that saving 3 or 4 minutes a day for the worst case scenario in which some weird programmer does over 400 builds per day is worth the effort of removing a feature that costs nothing and many people find useful?

    My guess is that this is not the case at all and that this is just an excuse for the kind of sloppy work that permeates this product.

    Craig

    Wednesday, February 22, 2006 3:51 AM
  • I apologize for sounding condescending. That was not my intent. My intent was to address some of the specific points raised by the previous two posters.

    We made the wrong engineering decision to remove the feature.

    Friday, February 24, 2006 4:12 PM
    Moderator
  • Bill, please see this post: Tips for reporting issues on the Product Feedback Center

    It is certainly better if you report the issue yourself. You can link to this thread when you post there.

    Friday, February 24, 2006 4:26 PM
    Moderator
  • On a related note, since there is no sound, is there some other way to know when a commandline invoked build is finished?  The command:

    devenv stuff.sln /build

    returns to the prompt instantly.  At the moment, I'm listening for the fan in my PC to slow down as notice that the process is finished.

     

    Friday, February 24, 2006 4:29 PM
  • Make sure you're calling devenv.com instead of devenv.exe (if you've set up a shortcut or doskey alias)

    Alternatively, from a command line you could use "start /wait devenv.exe" but, as I implied, devenv.com should be doing that for you.

    Friday, February 24, 2006 9:28 PM
    Moderator
  • Thanks - I was, in fact, invoking the wrong version.

     

    Friday, February 24, 2006 9:45 PM
  • Moin Moin.
    Three, namely "MSVC_OutputError", "MSVC_OutputWarning", "MSVC_HitBP" were missing  from the list.
    Hence it should comprise the registry settings:
    ____________________________________________
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev]
    @="Microsoft Developer"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildComplete]
    @="Build Complete"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildComplete\.current]
    @="c:\\WINdows\\ST\\SOUND\\Nicely-d.wav"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildError]
    @="Build Error"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildError\.current]
    @="c:\\WINdows\\ST\\SOUND\\Question.wav"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildWarning]
    @="Build Warning"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\BuildWarning\.current]
    @="c:\\WINdows\\ST\\SOUND\\Nobodys-.wav"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_HitBP]
    @="Breakpoint Hit"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_HitBP\.current]
    @="c:\\WINdows\\ST\\SOUND\\Fascinat.wav"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_OutputError]
    @="Error in Output"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_OutputError\.current]
    @="c:\\WINdows\\ST\\SOUND\\Report-t.wav"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_OutputWarning]
    @="Warning in Output"
    [HKEY_CURRENT_USER\AppEvents\Schemes\Apps\MSDev\MSVC_OutputWarning\.current]
    @="c:\\WINdows\\ST\\SOUND\\Schokol2.wav"

    ____________________________________________
    _Tschuess,
    __Michael.
    Monday, February 27, 2006 10:23 AM
  • For anyone interested, Bill Rubin has logged suggestion FDBK46424 for this on the Product Feedback Center at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=FDBK46424

    Vote away!

    Friday, March 3, 2006 4:03 PM
    Moderator
  • Paul, if the breakpoint audio cue is still implemented, how does removing all the other audio cues relieve intialization of multimedia DLLs?
    Friday, March 3, 2006 4:06 PM
    Moderator
  • I tried the workaround - no luck.  Once I got past the Macro editor's insistence that "Handles..." be on the previous line, the macro only works once.  The first time I build, the sound plays as expected.  If I immediately build again, sometime during the build the whole IDE hangs - requiring the Task Manager to put it out of its misery.

     

    Friday, March 31, 2006 8:58 PM
  • Thanks Bill, for opening the bug report. We are working on fixing this issue in the next release.

     

    Meanwhile, I just wanted to let you all know that if you like, you can solve this problem by creating your own add-in and with little coding using the extensibility feature of Visual Studio.

     

    I created a simple VB add-in as work around for this problem which works and thought you all would like to know the "how to" in case you are not familiar with creating add-ins.

     

    Please follow these simple steps to create and start using your own add-in:

     

    1) File - > new - > project -> expand the node "Other project types" -> Extensibility -> Visual Studio Add-in and name your addin as say "BuildEventsSounds" and hit OK

     

    2) Select VB on page 1 of the add-in wizard , you can check both the boxes on page 2, add description as needed on the page 3, for this simple example you can skip checking any boxes on page 4 and 5 and hit finish on page 6. For those who didn't know,you can always hit F1 when you are on a wizard page to learn more about what different options in that page mean.

     

    3) Add a new WithEvents variable in the wizard generated class "Connect" to generate the build events , by simply inserting this line the class definition (in connect.vb , after "Dim _addInInstance As AddIn" statement):

    Public WithEvents bldevents as buildevents

     

    4) Add code to initialize the above variable in method OnConnection() (gets called when Visual Studio loads) , by inserting this line towards the end of this method body:

    bldevents = _applicationObject.Events.BuildEvents

     

    5) Add a new method to the "Connect" class , which handles the build events , which looks like this (plays just 2 different system provided sounds on build success and failure):

     

    Private Sub bldevents_OnBuildProjConfigDone(ByVal Project As String, ByVal ProjectConfig As String, ByVal Platform As String, ByVal SolutionConfig As String,

    ByVal Success As Boolean) Handles bldevents.OnBuildProjConfigDone

            If (Success = True) Then

                System.Media.SystemSounds.Exclamation.Play()

            Else

                System.Media.SystemSounds.Hand.Play()

            End If

    End Sub

     

    6) Build the BuildEventsSounds project ; provided no build errors show up, at this point your add-in is ready for registration and deployment.

     

    7) For registration , copy the BuildEventsSounds.Addin (in the same dir as solution file) and BuildEventsSounds.dll (in bin\debug dir) files to appropriate directories by following the instructions at http://msdn2.microsoft.com/en-us/library/19dax6cz(VS.80).aspx

    Note: If the dll file is not copied in the same directory as .addin file, then you would have to modify the <Assembly> tag in the .Addin file to indicate full-path for the dll.

     

    8) The next step is to load the add-in in Visual Studio IDE and instructions for doing it can be found in this link:

    http://msdn2.microsoft.com/en-us/library/xwdatdwh(VS.80).aspx

    Note: You must check the "Startup" column check box in the add-in manager for this add-in to work when new instance of Visual Studio is started.

     

    9) Close all instances of Visual Studio and start a new instance to allow your changes to take affect.

     

    That’s it! At this point, different sounds would be played when a project build succeeds or fails.

     

    You can always extend or modify the add-in code to suite your specific needs.

     

    Hope that helps and please let me know if you have any questions and I will be glad to help you further.

     

    Thanks,

    Rupesh

     

     

     

     

     

     

    Thursday, April 6, 2006 7:03 PM
    Moderator
  •  Rupesh Rao MSFT wrote:

     

    7) For registration , copy the BuildEventsSounds.Addin (in the same dir as solution file) and BuildEventsSounds.dll (in bin\debug dir) files to appropriate directories by following the instructions at http://msdn2.microsoft.com/en-us/library/19dax6cz(VS.80).aspx

    Note: If the dll file is not copied in the same directory as .addin file, then you would have to modify the <Assembly> tag in the .Addin file to indicate full-path for the dll.

     

    8) The next step is to load the add-in in Visual Studio IDE and instructions for doing it can be found in this link:

    http://msdn2.microsoft.com/en-us/library/xwdatdwh(VS.80).aspx

    Note: You must check the "Startup" column check box in the add-in manager for this add-in to work when new instance of Visual Studio is started.

     

     

    Could you elaborate on this a little?  I used the default location for the Project: 

    My Documents\Visual Studio\Projects\BuildEventsSounds

    but no matter where I move the .Addin and .dll files, it doesn't show up in the Add-in Manager dialog.

    Thanks.

    Friday, April 7, 2006 2:30 PM
  • Start using VS .net 2005 yesterday and found this thread, of course it's really annoying that there is no sound at the end of Buildprocess.
    I also have problems using the workaround and I changed the code, so that it works fine (for me).
    Maybe, someone find it useful.
    It playes the sounds defined for the build-events in system-control-panel->sounds.
    Hope it helps...

    Use the documentation  from the workaround: LINK and the following code instead.

        Public bBuildErr As Boolean = False

        ' The DLL Import that plays the sounds
        Declare Function sndPlaySound Lib "winmm.dll" _
            Alias "sndPlaySoundA" (ByVal lpszSoundName As String, _
            ByVal uFlags As Long) As Long

        ' A convenience method to play the sound
        Private Sub PlaySound(ByVal sSoundFile As String)
            'Play async, ignore file not found
            sndPlaySound(sSoundFile, &H1 Or &H2 Or &H20000)
        End Sub

        Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone
            Dim sSound As String

            If bBuildErr Then
                sSound = My.Computer.Registry.GetValue( _
                    "HKEY_CURRENT_USER\AppEvents\Schemes\Apps\devenv\VS_BuildFailed\.current", _
                    "", "").ToString()
            Else
                sSound = My.Computer.Registry.GetValue( _
                    "HKEY_CURRENT_USER\AppEvents\Schemes\Apps\devenv\VS_BuildSucceeded\.current", _
                    "", "").ToString()
            End If
            PlaySound(sSound)
            bBuildErr = False
        End Sub

        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
            If Not Success Then
                bBuildErr = True
            End If
        End Sub

    Friday, April 7, 2006 3:49 PM
  •  geg wrote:
    Start using VS .net 2005 yesterday and found this thread, of course it's really annoying that there is no sound at the end of Buildprocess.
    I also have problems using the workaround and I changed the code, so that it works fine (for me).
    Maybe, someone find it useful.

    Bless you - it works!

    Friday, April 7, 2006 4:04 PM
  • Hi Jim,

    Actually project location doesn't matter. But the .addin should be in one of these locations to show up in Add-in manager dialog.

    \Documents and Settings\<user name>\My Documents\Visual Studio 2005\Addins

    OR

    \Documents and Settings\All Users\My Documents\Visual Studio 2005\Addins

    Are you getting any error messages when you click tools-> Add-in Manager ... (after copying the files to right location) ? or are you just not seeing it in add-in manager even after copying it in one of above locations ? Can you try closing all instances of VS and starting a new instance after copying files ?

    Also , where did you copy the .dll file ? in the same directory as .addin file or somewhere else (needs modification of .addin file to work) ?

    Thanks,

    Rupesh

     

    Friday, April 7, 2006 5:06 PM
    Moderator
  • Rupesh,

    Between posting the question and your answer, geg posted the modified macro workaround - which works for me - so I gave up on the Addin.

    Thanks anyway,

    Jim

     

    Friday, April 7, 2006 5:12 PM
  • Thanks so much to Rupesh Rao, Mike Welch (codefez.com), and geg for a build-sounds work-around.  I've been using geg's version for some time, and am pretty happy with it. It's 98 percent better than having no sound at all.

    The only issues I've noticed are:

    1. "Build succeeded" sound also occurs now when I hit F5 (Debug).  But this is only a very small annoyance I can tolerate.

    2. Visual Studio sometimes seems to crash when I exit it, expecially when a solution is still loaded.  (I'm not certain this is due to the macro.)

    These problems will presumably be solved with the new release of Visual Studio.  Anyway, thanks again to everyone for all the help.

     

    Wednesday, June 7, 2006 3:42 PM
  •  Bill Rubin wrote:
    1. "Build succeeded" sound also occurs now when I hit F5 (Debug).  But this is only a very small annoyance I can tolerate.

    I fixed this issue, see the new improved version below.

     Bill Rubin wrote:
    2. Visual Studio sometimes seems to crash when I exit it, expecially when a solution is still loaded.  (I'm not certain this is due to the macro.)

    This behavior, I can't acknowledge.

     
        Public bBuildErr As Boolean = False
        Public iCnt As Integer = 0

        ' The DLL Import that plays the sounds
        Declare Function sndPlaySound Lib "winmm.dll" _
            Alias "sndPlaySoundA" (ByVal lpszSoundName As String, _
            ByVal uFlags As Long) As Long

        ' A convenience method to play the sound
        Private Sub PlaySound(ByVal sSoundFile As String)
            'Play async, ignore file not found
            sndPlaySound(sSoundFile, &H1 Or &H2 Or &H20000)
        End Sub

        Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone
            Dim sSound As String

            If iCnt > 0 Then
                If bBuildErr Then
                    sSound = My.Computer.Registry.GetValue( _
                        "HKEY_CURRENT_USER\AppEvents\Schemes\Apps\devenv\VS_BuildFailed\.current", _
                        "", "").ToString()
                Else
                    sSound = My.Computer.Registry.GetValue( _
                        "HKEY_CURRENT_USER\AppEvents\Schemes\Apps\devenv\VS_BuildSucceeded\.current", _
                        "", "").ToString()
                End If
                PlaySound(sSound)
            End If
            bBuildErr = False
            iCnt = 0
        End Sub

        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
            iCnt += 1
            If Not Success Then
                bBuildErr = True
            End If
        End Sub

    Wednesday, June 7, 2006 4:23 PM
  • Excellent!  This solves the problem of gratuitous sounds when starting debug in C++.  Thanks very much!

    FWIW, a very minor point:  If project is C# instead of C++, gratuitous "build complete" sound still occurs when entering Debug.  I guess that's why the best solution is the new Visual Studio.

     

    Wednesday, June 7, 2006 5:32 PM
  • I used Build Failed and Build Succeeded most.  It was often helpful to also have Breakpoint Hit.
    Saturday, August 12, 2006 5:35 PM
  •  Paul Harrington MSFT wrote:

    Here are three tips to avoid having to read and parse the (entire) output window:

    1. Look in the status bar. It says "Build succeeded" if there are no errors.

    2. Open the Error List tool window. If all is well, there will be no errors reported.

    3. The last line of the output window is a summary line indicating how many builds failed.

    Your request for the return of audio cues can be logged in the product feedback center.

    Jweisz, The audio cues were removed for performance reasons. Initializing the multimedia DLLs to play the sounds was costing several hundred milliseconds in some high priority performance scenarios (edit/build//debug cycle).

     

    I agree with the others here, what an obnoxious post - especially when you are representing Microsoft.

     

    As for the removal of audio due to 'performance reasons' in the order of 'hundred milliseconds' I would like to see your data.  This would only become a problem if the audio playback had a large percentage in the entire build process use case.  However I can not think of any reasonably large solutions that only compile in a matter of seconds!  So who cares about a few hundred milliseconds compared to say a 20 second build, let alone builds that take minutes.

     

    If you are worried about resources, please explain to me that in my solution of 10 projects that VS2005 rightly so finds in error in one of my core projects but then continues to build the rest of the solution all of which are dependant on the project with errors?  It just fills up the error list with redundant information.

    Wednesday, August 15, 2007 8:13 AM
  • Micky D,

     

    I'm sorry that you found my post obnoxious and I shall, in future, be more mindful of the community's sensitivity.

     

    The data you requested are no longer available. The delay is caused by initializing the audio playback stack which, on some combinations of operating system and hardware, can be significant. The build scenarios that we measure and track involve solutions of all sizes. As you rightly point out, a delay of a few hundred milliseconds on top of a twenty second build would not be significant.

     

    As I have said previously, it is regrettable that the wrong engineering decision was made to remove audio cues from solution build events.

     

    Thursday, August 30, 2007 2:03 PM
    Moderator
  •  Paul Harrington MSFT wrote:

    The delay is caused by initializing the audio playback stack which, on some combinations of operating system and hardware, can be significant.

     

    Simply workaround this problem, needs to implement configuration setting "Use build complete notification sounds Yes/No"...

    Thursday, August 30, 2007 2:33 PM
  • As pointing out by geg, why not simply use a yes or no option, that would resolve the problem, im really mad about this "missing feature" and im sure there is a lot of us that would like to have it back in oracas. And for the millisecound issue, unless u have a 486, i really doubth that playing a sound will take sinificant time, if so, then people can turn them off themself in the control panel anyway...

     Please don't let us down!
    (Alose, why did they leave the breakpoint one, but removed the most usefull one???)

    Regard
    Sunday, October 21, 2007 8:07 PM