I’ve just hit this again so I decided to share the solution in case anyone else hits this.
Symptom: Visual Studio freezes for about a minute after you hit F5 (but before the app actually starts), then suddenly unfreezes and happily proceeds to launch the app.
Cause: VS calls the Windows CreateFile function on one of the paths specified in Tools –> Options –> Debugging –> Symbols –> Symbol file (.pdb) locations and that location either doesn’t exist or can’t be accessed (e.g. due to misconfigured DNS settings).
Solution: Check that all network paths in the list above can be accessed normally.
If you launch ProcMon.exe before starting debugging and configure the filter to only monitor “devenv.exe”, Result = “BAD NETWORK PATH”, it should show you which CreateFile call causes a network timeout.
* http://support.microsoft.com/kb/951336 * http://social.msdn.microsoft.com/forums/en/vsdebug/thread/1ede20ce-b236-4361-8dcb-04189b607152
This seems to be commonly known and accepted best practice to use DateTime.UtcNow for non-user facing scenarios such as time interval and timeout measurement.
I’ve just done an audit of the Roslyn codebase and replaced most DateTime.Now calls with DateTime.UtcNow. I thought it’d be useful to post my changeset description here (although none of it is new – I just summarize some common knowledge readily available in the sources linked below).
Replacing DateTime.Now with DateTime.UtcNow in most cases.
We should be using DateTime.Now only in user-facing scenarios. It respects the timezone and Daylight Savings Time (DST), and the user feels comfortable when we show them the string that matches their wall clock time.
In all other scenarios though DateTime.UtcNow is preferable.
First, UtcNow usually is a couple of orders of magnitude faster, since Now is basically first calling UtcNow and then doing a very expensive call to figure out the time zone and daylight savings time information. Here’s a great chart from Keyvan’s blog (modified to avoid allocations of the Stopwatch object):
Second, Now can be a big problem because of a sudden 1-hour jump during DST adjustments twice a year. Imagine a waiting loop with a 5-sec timeout that happens to occur exactly at 2am during DST transition. The operation that you expect to timeout after 5 sec will run for 1 hour and 5 seconds instead! That might be a surprise.
Hence, I'm replacing DateTime.Now with DateTime.UtcNow in most situations, especially polling/timeout/waiting and time interval measurement. Also, everywhere where we persist DateTime (file system/database) we should definitely be using UtcNow because by moving the storage into a different timezone, all sorts of confusion can occur (even "time travel", where a persisted file can appear with a future date). Granted, we don't often fly our storage with a supersonic jet across timezones, but hey.
For precise time interval measurements we should be using System.Diagnostics.StopWatch which uses the high resolution timer (QueryPerformanceCounter). The resolution of both DateTime.Now and DateTime.UtcNow is very low – about 10 ms – this is a huge time interval!
For a cheap timestamp, we should be generally using Environment.TickCount - it's even faster than DateTime.UtcNow.Ticks.
I'm only leaving DateTime.Now usages in test code (where it's never executed), in the compiler Version parsing code (where it's used to generate a minor version) and in a couple of places (primarily test logging and perf test reports) where we want to output a string in a local timezone.
* http://www.keyvan.ms/the-darkness-behind-datetime-now * http://stackoverflow.com/questions/62151/datetime-now-vs-datetime-utcnow * http://stackoverflow.com/questions/28637/is-datetime-now-the-best-way-to-measure-a-functions-performance