Visual Studio Builds per day

Question

Is there any way to log the number of builds done during a development day in Visual Studio, or anywhere we can hook into something to get at the metadata?

I'm curious how many times on average I build/day * how long it takes per build...

Any thoughts?

UPDATE: sorry for the lack of details...and this exercise is purely academic

With a solution that has 14 different projects (1 is a web site). I am constantly building the entire solution (Ctrl + Shift + B). It would be interesting to find out not only the number of times I build during the day, but how much time is spent waiting for a build to complete...

The optimal solution would be one that doesn't require a change to the solution's projects itself. (pre/post build events) I don't want to have to add/undo changes before/after check-ins.

(The nant/other solution is sounding like the answer, I guess I could map that to a shortcut key and not have to leave VS to do the build)

Any other suggestions?

Answer 1

It might be overkill, but you can write your own logging utility to log metadata about the build for each project. Keep track of the build count that day through your logging class.

Please see this link about extending MSBuild logging and this link about extending MSBuild with custom tasks.

Answer 2

One option would be to create a couple of scripts in your favorite scripting language and add them to the pre and post build events of the project settings.

Now every time you run a build the scripts will be run and you can have the scripts track whatever information you require.

But naturally this will only work at a project level and not automatically across all projects.

Answer 3

If you're building the same project each time, you can easily write a little script to execute in the "Pre-build tasks" section of your Project properties (click the "Build events" button at the bottom of the Compile tab of the properties page).

Answer 4

VS only allows you to hook into project level build events so if this isn't enough you can use a build script (MSBuild, NAnt etc) to build the solution which will give you full controll over what happens before and/or after the build.

To be honest though what benifit would you get from these stats on a local machine? We use a build server CCNET http://ccnet.thoughtworks.com/ that tracks build times and Unit test times, and is triggered after a commit to our source control SVN http://www.collab.net/downloads/subversion/ I'd recommend this approach for gathering stats.

Answer 5

Use your macro explorer an edit the EnvironmentEvents Module. You could use a database instead of a file.

Private BuildStopWatch As System.Diagnostics.Stopwatch = New System.Diagnostics.Stopwatch()

Private Sub BuildEvents_OnBuildBegin(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildBegin
    BuildStopWatch.Reset()
    BuildStopWatch.Start()
End Sub

Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone
    BuildStopWatch.Stop()
    DTE.ToolWindows.OutputWindow.ActivePane.OutputString("Build succeed in " & BuildStopWatch.Elapsed.TotalSeconds & " seconds.")
    Dim fileName As String = "D:\BuildTimes.txt"
    Try
        Dim streamWriter As StreamWriter
        If File.Exists(fileName) Then
            streamWriter = File.AppendText(fileName)
        Else
            streamWriter = File.CreateText(fileName)
        End If

        streamWriter.WriteLine(DateTime.Now.ToString() & "    " & "Build Time:" & BuildStopWatch.Elapsed.TotalSeconds)
        streamWriter.Close()
        streamWriter.Dispose()
    Catch ex As Exception
        MsgBox(ex.Message)
    End Try

End Sub

Answer 6

Make sure your EnvironmentsEvents module imports the System.IO namespace to be able to access the StreamWriter and File calls.

Answer 7

http://www.codeproject.com/KB/macros/Increment_Build_Number.aspx

This worked for me, but be sure to Import the System.IO namespace in your EnvironmentsEvents module as Shawn suggested.