[Warning] Cannot parse current item's date '1/1/0001 12:00:00 AM'


Get a lot of warning
[Warning] Cannot parse current item's date '1/1/0001 12:00:00 AM'
And nothing is incremented in VS 2011 SP1.
I'm using the latest beta.

file attachments


cpmo wrote Dec 28, 2011 at 8:57 PM

Same: v2.5.11231.2247 [Beta]

cpmo wrote Dec 29, 2011 at 11:05 AM

I'm from Brazil, the official date time format is: HH:MM dd/mm/yyyy

eliotvanuytfanghe wrote Jan 26, 2012 at 8:16 PM

Same problem here, even worse when I built my project it messed up all the library references, had to reconfigure them then I just deleted this extension since all it did was decrement the build instead :/

< Same date time format as op.

wrote Feb 28, 2012 at 10:25 AM

donnicky wrote Feb 28, 2012 at 10:25 AM

Since a moment having the same problem. :( Screens and VS solution in the attachment. But the problem is in every solution.

wrote Feb 28, 2012 at 10:28 AM

wrote Feb 21, 2013 at 11:57 PM

frazou wrote Apr 26, 2013 at 3:15 PM

I had the same problem with VS2010 SP1.But after deleting all files from previous versions of BuildVersionIncrement it worked great!

wrote Jun 7, 2013 at 1:49 PM

gerwulf wrote Jun 7, 2013 at 1:49 PM

I uploaded a patch for BuildVersionIncrementor.cs which uses CultureInfo.InstalledUICulture instead of CurrentCulture. This way, it tries to parse the date string in the OS's culture first (even if the IDE is using en-US for its threads (and thus, its add-ins)), then defaults to the invariant culture (en-US) in case of errors.

Try it - this now works for me (english VS 2010 SP1 on german WinXP SP3).

wrote Jun 11, 2013 at 10:04 AM

BenXXX wrote Jun 11, 2013 at 10:04 AM

Hi everybody

I suffered this "Warning mess" also. So I solved it (at least for me) and provide the code/thoughts here.

Windows 7, english
Visual Studio, english (are there other versions? Dunno..)
Local Settings set to another country than englisch/us

This is a common scenario for developers outside the empire. You want english error messages with which you can extract meaningful answers from google. Error messages in suaheli will not help much. But you dont want using these old fashioned elbow and foot measurements. And also use your local datetime.

Simple test in BuildVersionIncrementor.cs
Logger.Write(String.Format("Parse DateTime '{0}'", itemDateString), LogLevel.Info);
                    Logger.Write(String.Format("CultureInfo.InstalledUICulture.Name '{0}'", CultureInfo.InstalledUICulture.Name), LogLevel.Info);
                    Logger.Write(String.Format("CultureInfo.CurrentCulture.Name '{0}'", CultureInfo.CurrentCulture.Name), LogLevel.Info);
                    Logger.Write(String.Format("CultureInfo.CurrentUICulture.Name '{0}'", CultureInfo.CurrentUICulture.Name), LogLevel.Info);
                    Logger.Write(String.Format("CultureInfo.InvariantCulture.Name '{0}'", CultureInfo.InvariantCulture.Name), LogLevel.Info);
resulted in
[Info] Parse DateTime '22.01.2013 13:36:58'
[Info] CultureInfo.InstalledUICulture.Name 'en-US'
[Info] CultureInfo.CurrentCulture.Name 'en-US'
[Info] CultureInfo.CurrentUICulture.Name 'en-US'
[Info] CultureInfo.InvariantCulture.Name ''
==> Always US, but my system has european date format configured!
I don't know why in an VS Addin CurrentCulture delivers en-US. I tested a simple Winforms app. There, CurrentCulture delivers the currently configured format.

So, the workaround is to use Pinvoke:
using System.Runtime.InteropServices;

static extern uint GetUserDefaultLCID();

int lcid = Convert.ToInt32(GetUserDefaultLCID());
CultureInfo formattingCultInfo = new CultureInfo(lcid);
itemFileDate = DateTime.Parse(itemDateString, formattingCultInfo );

sgatemedia wrote Aug 28, 2013 at 1:17 PM

a small change in BuildVersionIncrementor.cs around line #190:

  itemFileDate = DateTime.Parse(itemDateString, CultureInfo.InvariantCulture);
  itemFileDate = DateTime.Parse(itemDateString, CultureInfo.InstalledUICulture);
made my visual studio 2012 running on a german windows 8 x64 installation forget about those nasty 'Cannot parse current item's date' messages.

wrote Jan 16, 2014 at 6:25 PM

Achimobil wrote Feb 25, 2014 at 12:02 PM

The problem still exists. When will that be solved?