I've just been working around the same error today in my umbraco/courier install
I managed to work around it (albeit not fully fix it) by:
1) I realised the issue is being caused by different locales on the servers I'm pushing between - one was set to uk and one set to us, hence the date format being different between them - 24/5/2012 on one, 5/24/2012 on the other.
2) I set the server (windows 2008 server) at the operating system (windows control panel - region and language) with the incorrect US locale setting to UK. once I did this, the date started appearing in the correct uk format when I typed "date" on the server's command prompt. I thought this would have sorted it, but it still threw the error. I noticed after creating and packaging a new courier revision, if I looked at the courier transfer log, it was still using the US date format. I compared ALL the umbraco and courier configs between the servers, and there was no trace of a Culture / en-us difference in any of the configs, so I can't figure out where courier is holding on to this us style date formatting from. I can only conclude it must pick up this system variable of date format at some initial point, and store it in the db. uninstalling and reinstalling courier didn't get it to pick up the new date format either.
3) so, I found that courier stores its packaged-up revisions in the umbraco app_data\courier\revisions folder , and that inside a revision there are 2x what I would refer to as "index" files, presumably containing info about what's in this revision. I searched through them for dates and amended the date formats on these two files manually, and the recieving server then happily installed the package - all is well. I'll be stuck doing this manual date replace task every time i make a package until I figure out where the courier packager is picking up its date format from.
Thanks Alan. I see two files: a "manifest.xml" and a "tt.couriercompare" (where "tt" is my test revision). Not sure which of those you're referring to.
In my case, I'm transferring between two Umbraco instances on the same server, as we're using the trial version of Courier. My management isn't ready to buy into Umbraco until I can convince them that we can get basic things working. Thus far, Umbraco is not making me look very good :^(
So actually I can reproduce this problem without even doing the actual transfer to another Umbraco instance. If I create a revision, and then attempt to do a "Compare and Install" of that revision on the same instance, I get the exception.
does courier on each of your instances, when creating revision packs, record the date in different formats then? do you know how/when your two instances ended up with different date formats, especially if they're on same server(s)? If you figure out how to actually get the date formatting fixed on the "bad"ly date/time formatted instance, let us know!
First to answer the question - both instances saved the files in the same date/time format, which is mm/dd/yyyy hh:mm:ss.
I took your suggestion and hand-edited the .couriercompare file, and changed the dates to dd/mm/yyyy hh:mm:ss format, and it works! Thanks!
In my case, the .couriercompare file has 3 "provider" elements, each of which in turn has a "compare" element. Each "compare" element has a "timestamp" element, and each one must be hand-edited. Knowing as little about Courier as I do, I suppose it's possible that there may be fewer or more of these "provider" elements.
Also note that I'm using the 2.6.18 build which is dated only a few days ago. I originally reported this to Umbraco over a week ago, but we do not have a support agreement, so there is no feedback to be had.
My problems started on 13/05, it seems that when the revision packed is created it is always done in US date format, but when it is compared it is done in DD/MM/yyyy format, I just forwarded my server date to the 01/06, and repacked all my revisions, and then it is working fine again.
Via my employer, we have submitted a Confidence ticket on this issue. Please let us know if there are any additional details that we can provide to aid resolution.
I want to note for anyone else reading this thread that HQ got back to us within the allotted Confidence support time window. I missed their initial response due to a mixup on our own end. A fix is already targeted for 2.7. After testing the nightly, I will post the results back to this thread.
String was not recognized as a valid DateTime.
System.NullReferenceException: Object reference not set to an instance of an object.
at Umbraco.Courier.Core.Storage.RevisionStorage.(String folderName, String path, Revision& revision)
at Umbraco.Courier.Core.Storage.RevisionStorage.GetFromDirectory(String name, String directory)
at Umbraco.Courier.UI.Pages.ViewRevisionDetails.Page_Load(Object sender, EventArgs e)
at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at umbraco.BasePages.BasePage.OnLoad(EventArgs e)
at Umbraco.Courier.UI.Pages.CourierBasePage.OnLoad(EventArgs e)
at Umbraco.Courier.UI.Pages.CourierBaseLicensedPage.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
I just installed the latest build and still get this exception. We cannot use Umbraco without Courier.
I've just been working around the same error today in my umbraco/courier install
I managed to work around it (albeit not fully fix it) by:
1) I realised the issue is being caused by different locales on the servers I'm pushing between - one was set to uk and one set to us, hence the date format being different between them - 24/5/2012 on one, 5/24/2012 on the other.
2) I set the server (windows 2008 server) at the operating system (windows control panel - region and language) with the incorrect US locale setting to UK. once I did this, the date started appearing in the correct uk format when I typed "date" on the server's command prompt. I thought this would have sorted it, but it still threw the error. I noticed after creating and packaging a new courier revision, if I looked at the courier transfer log, it was still using the US date format. I compared ALL the umbraco and courier configs between the servers, and there was no trace of a Culture / en-us difference in any of the configs, so I can't figure out where courier is holding on to this us style date formatting from. I can only conclude it must pick up this system variable of date format at some initial point, and store it in the db. uninstalling and reinstalling courier didn't get it to pick up the new date format either.
3) so, I found that courier stores its packaged-up revisions in the umbraco app_data\courier\revisions folder , and that inside a revision there are 2x what I would refer to as "index" files, presumably containing info about what's in this revision. I searched through them for dates and amended the date formats on these two files manually, and the recieving server then happily installed the package - all is well. I'll be stuck doing this manual date replace task every time i make a package until I figure out where the courier packager is picking up its date format from.
Hope this helps you
Thanks Alan. I see two files: a "manifest.xml" and a "tt.couriercompare" (where "tt" is my test revision). Not sure which of those you're referring to.
In my case, I'm transferring between two Umbraco instances on the same server, as we're using the trial version of Courier. My management isn't ready to buy into Umbraco until I can convince them that we can get basic things working. Thus far, Umbraco is not making me look very good :^(
-- Paul
that's right - theyre the files
So actually I can reproduce this problem without even doing the actual transfer to another Umbraco instance. If I create a revision, and then attempt to do a "Compare and Install" of that revision on the same instance, I get the exception.
does courier on each of your instances, when creating revision packs, record the date in different formats then? do you know how/when your two instances ended up with different date formats, especially if they're on same server(s)? If you figure out how to actually get the date formatting fixed on the "bad"ly date/time formatted instance, let us know!
First to answer the question - both instances saved the files in the same date/time format, which is mm/dd/yyyy hh:mm:ss.
I took your suggestion and hand-edited the .couriercompare file, and changed the dates to dd/mm/yyyy hh:mm:ss format, and it works! Thanks!
In my case, the .couriercompare file has 3 "provider" elements, each of which in turn has a "compare" element. Each "compare" element has a "timestamp" element, and each one must be hand-edited. Knowing as little about Courier as I do, I suppose it's possible that there may be fewer or more of these "provider" elements.
Also note that I'm using the 2.6.18 build which is dated only a few days ago. I originally reported this to Umbraco over a week ago, but we do not have a support agreement, so there is no feedback to be had.
Hope this helps a bit?
Now on to testing it a bit more!
-- Paul
My problems started on 13/05, it seems that when the revision packed is created it is always done in US date format, but when it is compared it is done in DD/MM/yyyy format, I just forwarded my server date to the 01/06, and repacked all my revisions, and then it is working fine again.
Frank
I am facing this exact issue. Is a comprehensive solution available?
Via my employer, we have submitted a Confidence ticket on this issue. Please let us know if there are any additional details that we can provide to aid resolution.
It may be completely irrelevant for troubleshooting purposes, but I have noticed an inconsistency in of the DateTime format in the log_Timer.txt file.
15/06/2012 15:55:27: 0 MS: Loading factory
6/15/2012 4:00:06 PM: 0 MS: Start Packaging ftuo-website-mbox-part2-omar
I want to note for anyone else reading this thread that HQ got back to us within the allotted Confidence support time window. I missed their initial response due to a mixup on our own end. A fix is already targeted for 2.7. After testing the nightly, I will post the results back to this thread.
Issue resolved as of 2.7.0.28
http://nightly.umbraco.org/UmbracoCourier/2.7/nightly%20builds/
Also quite pleased with performance.
is working on a reply...