Finally the buildserver issue has been resolved. As the last couple of days, the automated builds has been missing files, which has been leading to various strange errors.
This is now fixed, so nightly builds now include all files needed, and current tests for packaging sites passes on V6.
Per, great news the nightlies for 6 are available. Run some simple tests, and didn't find any problems. Also tested it in a scenario where the destination server was still running Umbraco 4.9, and that worked ok. Guess the dependency level selector for right click deploys is still in the works - be wonderful when that gets reinstated. James.
I've upgraded my project to v6.0.2 and Courier 2.7.4 b80 (for 6) and now i'm getting a consistent fatal error every time I try to package or transfer. Any idea on whats wrong???
error:Umbraco.Courier.Core.Exceptions.PackageException: Unable to load item with id '8c8f4e2f-520a-467f-9dd6-aebcbee9b834' from provider 'Media Property Data' ---> Umbraco.Courier.Core.Exceptions.RetrieveException: Error retrieving item [8c8f4e2f-520a-467f-9dd6-aebcbee9b834] from provider [e047259a-e73b-11df-9492-0800200c9a66]. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Umbraco.Courier.Persistence.V6.NHibernate.Persisters.ContentPropertyDataItem.RetrieveItem[T](ItemIdentifier itemId) in c:\Program Files (x86)\teamcity\buildAgent\work\650bafc4b83aa858\Core\Umbraco.Courier.Persistence.V6.NHibernate\Persisters\ContentPropertyData.cs:line 167 at Umbraco.Courier.Core.ItemCrudProvider.RetrieveItem[T](ItemIdentifier itemId) --- End of inner exception stack trace --- at Umbraco.Courier.Core.ItemCrudProvider.RetrieveItem[T](ItemIdentifier itemId) at Umbraco.Courier.ItemProviders.ItemProviders.MediaPropertyItemProvider.HandlePack(ItemIdentifier id) at Umbraco.Courier.Core.ItemProvider.Package(ItemIdentifier id) at Umbraco.Courier.RepositoryProviders.Local.Package(ItemIdentifier itemId) at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageItem(ItemIdentifier itemId, ItemProvider provider, QueuedItemIdentifier itemInQueue) --- End of inner exception stack trace --- at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageItem(ItemIdentifier itemId, ItemProvider provider, QueuedItemIdentifier itemInQueue) at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageBatch() at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageBatch() at Umbraco.Courier.Core.Packaging.RevisionPackaging.Package() at Umbraco.Courier.Core.Tasks.PackagingTask.Run() at Umbraco.Courier.Core.TaskManager.manageTask(IRevisionTask value) 07/03/2013 15:43:01
I've spent the last couple of days playing around with various v4.11.x/v.6.0.x Umbraco builds and since Per got his server back up and started submitting v6 compatible builds of Courier things have clearly gone a bit tits up! Due to that fact Courier is so "tightly coupled" to Umbraco, the problem almost certainly goes hand-in-hand with recent umbraco minor patch fixes.
So I've hit a brick wall at umbraco v4.11.4 and Courier 2.7.4 b67. Any attempts to go any further (including v6) results in Courier failing miserably for me!
It's becoming painfully obvious to me that I wont be able to keep my builds patched as often as i'd hoped (and get past a great many umbugs) due to my reliance on Courier.
"Nightly" builds can appear in rapid succession and when they do, you have to test, test, test before there's any confidence of going forward. I suppose my biggest beef is with the poor communication.
Despite Courier being pretty crucial for my projects this also appears to be one of the quietest areas on our.umbraco.org. So when I put out questions I dont often get answers back from the wider community either. The whole thing leaves me quite frustrated on a daily basis!
Oh well I guess I'll just have to be patient, and wait and see what happens!
This post is for all of you out there fighting over Courier 2 versions, I thought i'd post up my discoveries in the hope it might save some time and hair pulling!
NO guarantees are offered if you use these builds and believe me results vary wildly from one to the next!.
I've patched up my latest project to Umbraco version 4.11.5 and dropped in the MacroEngines.dll from 4.11.6 due to rendering problems. Extension plugins I run in this project include; Contour version 3.0.9 (latest MVC and Razor dlls). uComponents version 5.4.0. FamFamFam icons and FilteredMemberPicker version 1.0. Thats basically it! Other than a few of our own user controls and some razor it's nothing particularly taxing on the system.
After I posted a number of rants at Per over the failure of Courier in sending across media items correctly (particularly in the tinyMCE). He worked with me and on the 16th Jan 2013 posted up Courier 2.7.4. build 53.
I confirmed to Per the fix partially worked, as it still wasnt sending across media items with their folder structures intact. I can confirm a courier.config setting change is required to fix this...
<mediaItemProvider>
<!-- Changed to false in 2.1.1 -->
<includeChildren>true</includeChildren>
<includeParents>true</includeParents>
</mediaItemProvider>
I have no idea why this is false by default, it could be due to underlying problems with Courier (ie set it to true at your own risk!). There have been issues over unpublished/saved transfers which resulted in config entries being added (turns bugs on or off! lol). So be aware changing these settings might give undesired/unexpected results.
So what works "reliably" in build 53?
Published nodes, their dependencies and their children transfer, "mostly" without error
You can build seperate packages "mostly" without error
Media transfers correctly with folder structures intact
If you turn on unpublished transfers, 'publish at' gets transferred with your documents. (see below)
What doesnt work or considered "unreliable"?
Unpublished/saved transfers (unless you explicity turn this on in the web.config add, <ignoreUnpublishedVersions>false</ignoreUnpublishedVersions> to settings in the courier.config. Per has stated in a courier post that turning this on can lead to undesirable results.
The "big red" errors do still sometimes rear up, if they do try transferring again.
I've tested every build beyond 53 in Umbraco 4.11.5 and 6.0.2. The "big red" errors become fatal and Courier fails to recognise dependencies. So I would suggest for now sticking to build 53 until Per manages to stabilize the project.
For those of you hoping to use Courier with Umbraco 6 you'll be dissappointed, but if I find a way of getting b53 working on Umbraco 6, i'll let you know. I'm hoping a new stable build will appear soon enough though, keeping my crossing fingers now!
I didnt have any luck with Umbraco 6 and Courier build 53 unfortunately. I get a mountain of SQL ADO errors!
I tried Umbraco 6.0.2 and build 80 one last time and managed to get around the fatal "big red" errors. I think the fatal errors were happening because I didnt realise the project has a change in its DLLs and I wasnt careful enough to ensure old Courier DLLs were removed!
So with much trepidation I started transferring nodes...unfortunately I couldnt get build 80 to transfer without content getting completely muddled up. Lots seems to get shoved in the root and it all ends up in a horrible mess, very quickly! Real shame!
So as with my previous post, I'm sticking with build 53 for now.
Nightly builds for V6 Available
Finally the buildserver issue has been resolved. As the last couple of days, the automated builds has been missing files, which has been leading to various strange errors.
This is now fixed, so nightly builds now include all files needed, and current tests for packaging sites passes on V6.
http://nightly.umbraco.org/UmbracoCourier/2.7.4/nightly%20builds/
Per, great news the nightlies for 6 are available. Run some simple tests, and didn't find any problems. Also tested it in a scenario where the destination server was still running Umbraco 4.9, and that worked ok. Guess the dependency level selector for right click deploys is still in the works - be wonderful when that gets reinstated. James.
Hi Per
I've upgraded my project to v6.0.2 and Courier 2.7.4 b80 (for 6) and now i'm getting a consistent fatal error every time I try to package or transfer. Any idea on whats wrong???
error:Umbraco.Courier.Core.Exceptions.PackageException: Unable to load item with id '8c8f4e2f-520a-467f-9dd6-aebcbee9b834' from provider 'Media Property Data' ---> Umbraco.Courier.Core.Exceptions.RetrieveException: Error retrieving item [8c8f4e2f-520a-467f-9dd6-aebcbee9b834] from provider [e047259a-e73b-11df-9492-0800200c9a66]. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Umbraco.Courier.Persistence.V6.NHibernate.Persisters.ContentPropertyDataItem.RetrieveItem[T](ItemIdentifier itemId) in c:\Program Files (x86)\teamcity\buildAgent\work\650bafc4b83aa858\Core\Umbraco.Courier.Persistence.V6.NHibernate\Persisters\ContentPropertyData.cs:line 167 at Umbraco.Courier.Core.ItemCrudProvider.RetrieveItem[T](ItemIdentifier itemId) --- End of inner exception stack trace --- at Umbraco.Courier.Core.ItemCrudProvider.RetrieveItem[T](ItemIdentifier itemId) at Umbraco.Courier.ItemProviders.ItemProviders.MediaPropertyItemProvider.HandlePack(ItemIdentifier id) at Umbraco.Courier.Core.ItemProvider.Package(ItemIdentifier id) at Umbraco.Courier.RepositoryProviders.Local.Package(ItemIdentifier itemId) at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageItem(ItemIdentifier itemId, ItemProvider provider, QueuedItemIdentifier itemInQueue) --- End of inner exception stack trace --- at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageItem(ItemIdentifier itemId, ItemProvider provider, QueuedItemIdentifier itemInQueue) at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageBatch() at Umbraco.Courier.Core.Packaging.RevisionPackaging.PackageBatch() at Umbraco.Courier.Core.Packaging.RevisionPackaging.Package() at Umbraco.Courier.Core.Tasks.PackagingTask.Run() at Umbraco.Courier.Core.TaskManager.manageTask(IRevisionTask value) 07/03/2013 15:43:01
Per,
I'm also getting this error on every media item I'm trying to transfer. I'm running 4.11.5 and courier b80
Hi Vincent
I've spent the last couple of days playing around with various v4.11.x/v.6.0.x Umbraco builds and since Per got his server back up and started submitting v6 compatible builds of Courier things have clearly gone a bit tits up! Due to that fact Courier is so "tightly coupled" to Umbraco, the problem almost certainly goes hand-in-hand with recent umbraco minor patch fixes.
So I've hit a brick wall at umbraco v4.11.4 and Courier 2.7.4 b67. Any attempts to go any further (including v6) results in Courier failing miserably for me!
It's becoming painfully obvious to me that I wont be able to keep my builds patched as often as i'd hoped (and get past a great many umbugs) due to my reliance on Courier.
"Nightly" builds can appear in rapid succession and when they do, you have to test, test, test before there's any confidence of going forward. I suppose my biggest beef is with the poor communication.
Despite Courier being pretty crucial for my projects this also appears to be one of the quietest areas on our.umbraco.org. So when I put out questions I dont often get answers back from the wider community either. The whole thing leaves me quite frustrated on a daily basis!
Oh well I guess I'll just have to be patient, and wait and see what happens!
Martin
Hi all
This post is for all of you out there fighting over Courier 2 versions, I thought i'd post up my discoveries in the hope it might save some time and hair pulling!
Ok so first off, nightly builds can be found at http://nightly.umbraco.org/UmbracoCourier/2.7.4/nightly%20builds/
NO guarantees are offered if you use these builds and believe me results vary wildly from one to the next!.
I've patched up my latest project to Umbraco version 4.11.5 and dropped in the MacroEngines.dll from 4.11.6 due to rendering problems. Extension plugins I run in this project include; Contour version 3.0.9 (latest MVC and Razor dlls). uComponents version 5.4.0. FamFamFam icons and FilteredMemberPicker version 1.0. Thats basically it! Other than a few of our own user controls and some razor it's nothing particularly taxing on the system.
After I posted a number of rants at Per over the failure of Courier in sending across media items correctly (particularly in the tinyMCE). He worked with me and on the 16th Jan 2013 posted up Courier 2.7.4. build 53.
I confirmed to Per the fix partially worked, as it still wasnt sending across media items with their folder structures intact. I can confirm a courier.config setting change is required to fix this...
I have no idea why this is false by default, it could be due to underlying problems with Courier (ie set it to true at your own risk!). There have been issues over unpublished/saved transfers which resulted in config entries being added (turns bugs on or off! lol). So be aware changing these settings might give undesired/unexpected results.
So what works "reliably" in build 53?
What doesnt work or considered "unreliable"?
I've tested every build beyond 53 in Umbraco 4.11.5 and 6.0.2. The "big red" errors become fatal and Courier fails to recognise dependencies. So I would suggest for now sticking to build 53 until Per manages to stabilize the project.
For those of you hoping to use Courier with Umbraco 6 you'll be dissappointed, but if I find a way of getting b53 working on Umbraco 6, i'll let you know. I'm hoping a new stable build will appear soon enough though, keeping my crossing fingers now!
Martin
Hi all you courier fans!
I didnt have any luck with Umbraco 6 and Courier build 53 unfortunately. I get a mountain of SQL ADO errors!
I tried Umbraco 6.0.2 and build 80 one last time and managed to get around the fatal "big red" errors. I think the fatal errors were happening because I didnt realise the project has a change in its DLLs and I wasnt careful enough to ensure old Courier DLLs were removed!
So with much trepidation I started transferring nodes...unfortunately I couldnt get build 80 to transfer without content getting completely muddled up. Lots seems to get shoved in the root and it all ends up in a horrible mess, very quickly! Real shame!
So as with my previous post, I'm sticking with build 53 for now.
Martin
is working on a reply...