Visual Studio Builds per day

Is there a way to register the number of builds completed during the development day in Visual Studio, or wherever we are to get into the metadata?

I'm curious how many times on average I create / day *, how much time it takes to 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 - website). I am constantly building the whole solution (Ctrl + Shift + B). It would be interesting to know not only the amount of time that I build during the day, but how much time was spent waiting for the assembly to complete ...

The optimal solution is a solution that does not require a change in the draft decisions themselves. (events before / after assembly) I do not want to add / cancel changes before / after registration.

(The kernel / other solution sounds like an answer, I think I could match this with a shortcut key and should not leave VS to build)

Any other suggestions?

+7
build-process visual-studio
source share
7 answers

Use your macro volume to create a new macro. Open a new macro and edit the EnvironmentEvents module (you can leave another module empty). You can 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 
+4
source share

One option is to create several scripts in your favorite scripting language and add them to the events of the preliminary and subsequent assembly of the project parameters.

Now every time you run the assembly, the scripts are launched, and you can have scripts to track any information you need.

But, of course, this will work only at the project level, and not automatically in all projects.

+10
source share

This may be redundant, but you can write your own logging utility to record assembly metadata for each project. Keep track of the build amount that day through the logging class.

See this link for the MSBuild logging extension and this link for the custom task MSBuild extension.

0
source share

If you build the same project each time, you can easily write a little script to execute in the "Tasks before assembling" section of your project properties (click the "Build events" button at the bottom of the "Compilation" tab of the property page).

0
source share

Only VS allows you to connect to build events at the project level, so if this is not enough, you can use the build script (MSBuild, NAnt, etc.) to create a solution that will give you full control over what happens before and / or after assembly.

Honestly, what benefit could you get from these statistics on your local machine? We use the CCNET build server http://ccnet.thoughtworks.com/ , which tracks the build time and Unit test times, and starts after fixing to our SVN source http://www.collab.net/downloads/subversion/ I would recommend this approach is to collect statistics.

0
source share

Ensure that the EnvironmentsEvents module imports the System.IO namespace to access StreamWriter and File calls.

0
source share

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

This worked for me, but be sure to import the System.IO namespace into your EnvironmentsEvents module, as Sean suggested.

0
source share

All Articles