Wouldn’t it be great if we could get Visual Studio to do this for us automatically on build?  I thought so too, so I’ve written a little app to do it

Getting set up with “When The Version”

1. Go get a copy of “When The Version” (WTV.exe) from the GitHub download page (or you can build it from the source if you prefer)
2. Drop it somewhere on your PC
3. Now, in your Visual Studio project, expand the Properties and duplicate the AssemblyInfo.cs / .vb file – I rename the duplicate to be AssemblyInfo.Template.cs:

4. Edit the AssemblyInfo.Template.cs file, putting in the placeholders for the date parts like so:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("{YYYY}.{MM}.{DD}.0")]
[assembly: AssemblyFileVersion("{YYYY}.{MM}.{DD}.0")]

The following values are currently supported:

• {YYYY} – the year
• {MM} – the month
• {DD} – the day
• {SVN} – SubVersion revision number (more on this a bit later)

5. Now, open up the Project Properties > Build Events, and add the following Pre-build event command line (on a single line):

"C:\Path\To\wtv.exe"
  "$(ProjectDir)Properties\AssemblyInfo.Template.cs"
  "$(ProjectDir)Properties\AssemblyInfo.cs"

6. Finally, set the Build Action for the new AssemblyInfo.Template.cs file to ‘None’ and Build!

If you get stuck, pop open a Command Prompt and run WTV.exe without any parameters:

SubVersion support

If you’re using SubVersion for your source control, WTV can also put the projects SVN revision number into the application version.

There’s only one caveat – .Net Application version number values are limited to a maximum of 32,767 (i.e. they’re Int16′s). Therefore, if your SVN revision is higher WTV will only use the last 4 digits: e.g.: 32768 -> 2768.

To use the SVN revision number, simply add the {SVN} placeholder to your AssemblyInfo.Template.cs file like so:

[assembly: AssemblyVersion("{YYYY}.{MM}.{DD}.{SVN}")]
[assembly: AssemblyFileVersion("{YYYY}.{MM}.{DD}.{SVN}")]

.. and then add a couple of extra parameters to the Pre-build event command line so WTV knows where SubWCRev.exe is, something like this (again, on a single line):

"C:\Path\To\WTV.exe"
  "$(ProjectDir)Properties\AssemblyInfo.Template.cs"
  "$(ProjectDir)Properties\AssemblyInfo.cs"
  "C:\Program Files\TortoiseSVN\bin\SubWCRev.exe"
  "$(SolutionDir)."

 
And because the AssemblyInfo.cs is generated, you can remove it from source control (but don’t remove it from your project!)

Finally

Comments and suggestions are welcome here or on the projects issue tracker over at GitHub. I hope you find it useful

I was unsure because there is a consensus of small writes to SSDs aren’t as breathtaking as the reads and writes of larger files:

SATA-based SSDs generally exhibit much slower write speeds. As erase blocks on flash-based SSDs generally are quite large (e.g. 0.5 – 1 megabyte), they are far slower than conventional disks during small writes (write amplification effect) and can suffer from write fragmentation.

- Wikipedia

But these things are fast at everything else, and while mulling over the idea of upgrading for a few months, I started to notice my usage patterns of switching between lots of different supporting applications. Given that’d I’d get improvements elsewhere if not in Visual Studio, I decided to try it out for myself.

The SSD I chose is the Corsair CMFSSD-64D1, otherwise known as the Corsair Extreme Series X64:

Here are the timings I took with the original Samsung 80GB 7,200rpm drive, and the timings from the Corsair Extreme X64:
(all timings are in seconds, so lower numbers are better)

Conclusion

Overall, the SSD performs 53.6% faster – that means my machine is twice as responsive as it was.

However, the most important savings to me are loading, and building solutions – I’ve only been running the SSD for a couple of days, but already I have shaken the reflexive pause I felt before closing or restarting Visual Studio, or opening up different solutions.

Granted, building or compiling decent sized projects in Visual Studio on an SSD is not as impressively fast as spinning up applications (Outlook, Paint.Net or Dreamweaver for example), or the improvement in general system responsiveness.

I now get 3 complete builds for 2..  put simply, it’s almost fast enough to remove the build waiting tax. It’s fast enough that I don’t lose my train of thought and context switch to something else – which makes me more productive.

Method

Timings were taken manually with a stop-watch, and averaged over 3 data points on different days.

* The Windows logging in timings include a start-up anti-virus scan.

System Specification and software versions:

• Intel Pentium 4 HT, 3.0 GHz
• 3 GB RAM
• Windows XP 32bit (HDD timings), Windows 7 32bit (SSD timings)**
• Outlook 2007
• Visual Studio 2008 Team System Developer Edition
• The 8 project web solution is the fantastic invoice management software called SNAP, written in C# .Net 3.5

** yes, I’d have loved to have done an apples-to-apples comparison by copying the exact same Windows XP installation over to the SSD, and I was all set to do so, except the Samsung HDD had a series of faults around the ~36GB mark that resulted in an XP installation that would only boot into Safe Mode.

I had taken the timings the week before I found this out, and with a clean SSD it seemed crazy not to take the opportunity to upgrade to Windows 7.  I suspect that had I stayed on Windows XP, the speed improvements would have been more impressive.

Fortuitously, the Corsair SSD arrived the same morning that the Samsung HDD exhibited the fault. (I know what you’re thinking, and no, it definitely wasn’t sabotage.. the SSD was on order for 2 weeks prior, and wasn’t due to arrive for another 3 days)

The Solid State Drive upgrade is a definite improvement, and I don’t think I’ll be buying Hard Disk Drives any more