Have anyone had success with running Courier 2 on a site that already uses Castle.Core.dll and so on?
I am currently getting this when trying to add stuff to a revision:
NHibernate.ADOException: could not execute query
[ SELECT this_.id as id32_0_, this_.createDate as createDate32_0_, this_.level as level32_0_, this_.nodeObjectType as nodeObje4_32_0_, this_.nodeUser as nodeUser32_0_, this_.path as path32_0_, this_.sortOrder as sortOrder32_0_, this_.text as text32_0_, this_.trashed as trashed32_0_, this_.uniqueID as uniqueID32_0_, this_.parentID as parentID32_0_ FROM [umbracoNode] this_ WHERE this_.parentID = ? and this_.nodeObjectType = ? ]
Positional parameters: #0>-1 #1>b796f64c-1f99-4ffb-b886-4bf4bc011a9c
[SQL: SELECT this_.id as id32_0_, this_.createDate as createDate32_0_, this_.level as level32_0_, this_.nodeObjectType as nodeObje4_32_0_, this_.nodeUser as nodeUser32_0_, this_.path as path32_0_, this_.sortOrder as sortOrder32_0_, this_.text as text32_0_, this_.trashed as trashed32_0_, this_.uniqueID as uniqueID32_0_, this_.parentID as parentID32_0_ FROM [umbracoNode] this_ WHERE this_.parentID = ? and this_.nodeObjectType = ?] ---> System.IO.FileLoadException: Could not load file or assembly 'Castle.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at NHibernate.ByteCode.Castle.ProxyFactory.GetProxy(Object id, ISessionImplementor session)
at NHibernate.Tuple.Entity.AbstractEntityTuplizer.CreateProxy(Object id, ISessionImplementor session)
at NHibernate.Persister.Entity.AbstractEntityPersister.CreateProxy(Object id, ISessionImplementor session)
The most important part being:
System.IO.FileLoadException: Could not load file or assembly 'Castle.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Is this solvable by using assembly redirection? In our case we are using version 2.5.2.0, so there is quite a difference in version numbers.
@Per Not sure if you have done already, but you might want to look into using ILMerge to merge your DLL dependancies into a single DLL on your next release. We did this in UMP to allow provider developers to utilize various libraries without causing conflicts (the code will look for classes internally first, so you can run on a different version to any already in the bin, and also prevents conflicts with physical files).
Not really, as the space is going to get taken up anyway. The only time it would be a waste is if several other devs did the same, and you might end up with several version of NHibernate in your bin folder.
I think it would be excellent if *all* packages ILMerged their dependencies to keep this kind of carry-on to a minimum.
Having grappled for 5 hours trying to get Courier 2 and uCommerce to co-habitate, I thought I'd share my solution.
uCommerce and Courier 2 have 5 dlls with different versions in common:
Castle.Core
FluentNHibernate
Iesi.Collections
NHibernate.ByteCode.Castle
NHibermate
They share other dlls that have the same version too, but they don't cause any issues.
My directory structure at build-time is as follows:
- bin
[All assemblies except the 5 named above]
- Courier
[Courier versions of the 5 assemblies]
- uCommerce
[uCommerce versions of the 5 assemblies]
In web.config I added the following dependentAssembly entries (for some reason uCommerce seems to depend on version 1.0.1.0 of Iesi.Collections, which isn't distributed, but a redirect to the v2.1.2.4000 dll seems to work OK):
Your web.config entries above worked like a charm. One strange thing I noticed was that my Castle.Core assembly indicates version 2.5.2.0 instead of the above (2.5.1.0). I am using uCommerce 2.0.5.0. Strangely enough when I substitute 2.5.2.0 for the dependancy in web.config, I get errors. Somehow using 2.5.1.0 as you originally stated seems to work. Also noticed that the XSLT compile error states that it is looking for the 2.5.1.0 assembly even though the version that was downloaded with the package claims 2.5.2.0. Did you notice this issue as well?
Have you managed to get Courier and uCommerce both working at the same time? It's actually something I never managed, as there was an issue with the NHibernate dll that I couldn't work around. Essentially I was able to remove build errors by using the redirect, but a class or method that was being used in v2.1.2.400 wasn't present in v3.1.0.4000 - this meant that when the assembly was dynamically loaded, it blew up.
My solution in the end was to deploy two versions of Umbraco (using our own deployment framework) that both point at the same database. When they're deployed one gets the uCommerce dlls, and one gets the Courier dlls which means I can use both features from two different Umbraco instances. It smells, and I hate it, but it's the only solution I have found.
With regard to your question about 2.5.2.0 vs 2.5.1.0 - I noticed the same thing. Visual Studio reports the version as one thing, and Windows Explorer reports the other. Very strange!
Hope some of this helps you and I have saved you some of the pain I went through with this.
To be perfectly honest with you, I have yet to build out uCommerce in any way. Like you I was scratching my head with the dependancy problems and had just figured out the five libraries needing attention when I came across your post. Courier seems to work OK. Have you looked at Tea Commerce yet? I'm just dipping my toe in the e-commerce world so I claim ignorance at this point. If uCommerce is that difficult to manipulate then maybe I should look for something else? My apologies for straying off topic of this thread.
Courier's OK (although it has it's own set of idiosyncracies), and I think is a different class of add-on to uCommerce.
We've persisted with uComnmerce as it was the only Umbraco eCommerce add-on that had some specific features. That said, it hasn't been an easy road. The documentation consists of a series of blog posts by the author. When I say the API is hard to work with, here's an example (off the top of my head - I could come up with at least 10 major flaws).
A concept in uCommerce is a catalogue. Catalogues have an Id (int) and a Name (string) - all very straightforward. Where it starts to get very frustrating is when the API exposes methods like GetCatalogueByName(string name). You pass this method your catalogue's name, and it blows up. At this point you'll probably open Reflector and look under the bonnet to see what's going on. The method will take your name (string) argument, cast it to an int, and perform a look-up by Id! Unbelievable! So your code ends up littered with comments about why you're doing what you're doing because it looks counter-intuitive to the uninitiated.
We spent some time evaluating the various options, and uCommerce was the option we chose. Whilst it will (eventually) be fit for purpose in that we'll be able to run an eCommerce section of our site, the implementation time will be something like 3-4 times longer than I expected.
Gotcha, Thanks for the "heads-up". I looked at my commerce options for Umbraco and this one stood out as the most complete. I'm only evaluating the free version at this point and as you can tell I haven't gotten very far with it. I stumbled across tea commerce today by mistake. It advertises to be simple but extendable. I use an Intuit payment gateway so I can't just grab any shopping cart and expect them to accept it. My hope would be that uCommerce was used widely enough for Intuit to give me the go-ahead. Have you communicated these bugs to the author? Like you, when I see Get...ByName, I expect to use a string value. Sounds like your beta testing for the uCommerce team. ;) No offense towards them, they have obviously put a lot of effort into their product.
I'm sorry to hear that your experience with uCommerce is so bad.
The example you mention is quite a boo boo on our part. The idea was to try and maintain backwards compatibility with existing sites and have the API handle both names and ids. In hindsight we probably should have added another API and be done with it.
That said we do try and fix any errors discovered and reported by partners and I would appreciate any feedback or bug reports you can supply us with. You speed the process along by sending the reports directly to my email at ssl AT ucommerce DOT dk. We typically have a very rapid turnaround on bug reports, so specific issues are ironed out and builds sent to testing as they are made.
This is the first I hear about the issue, so naturally I will look into it and add a fix to the next release.
We do try and cover our code base with unit tests, but typically focus on the complicated engine pieces. It might be high time we expand the tests for the surface API. Even with a large tests suite it's impossible to cover all scenarios, doubly so for an API type product in which the use cases wary wildly.
Regarding the incompatiblity between Courier and uCommerce dependencies I can assure you we're working on fixing it as the issue will only become more pronounced when Umbraco 5 ships. We held off on fixing it as there were talks in the Umbraco Code Team on building the plugin model so each plugin would be self-contained thus the issue would be taken care of. Unfortunately this piece did not make it into the Umbraco 5 core, so we're currently working on ways of fixing it ourselves.
Shared dependency on Castle
Have anyone had success with running Courier 2 on a site that already uses Castle.Core.dll and so on?
I am currently getting this when trying to add stuff to a revision:
The most important part being:
System.IO.FileLoadException: Could not load file or assembly 'Castle.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Is this solvable by using assembly redirection? In our case we are using version 2.5.2.0, so there is quite a difference in version numbers.
So far, I've been able to solve it like this:
Yeah, that is the only way to solve it I think, thanks for bringing this up, I'll add it to the next release to update all our external dependencies
@Per Not sure if you have done already, but you might want to look into using ILMerge to merge your DLL dependancies into a single DLL on your next release. We did this in UMP to allow provider developers to utilize various libraries without causing conflicts (the code will look for classes internally first, so you can run on a different version to any already in the bin, and also prevents conflicts with physical files).
Matt
Not a bad idea, however, it is quite a big bunch of dlls, it's the entire set of nhibernate dlls, but that probably doesn't make a big difference?
Not really, as the space is going to get taken up anyway. The only time it would be a waste is if several other devs did the same, and you might end up with several version of NHibernate in your bin folder.
Matt
I think it would be excellent if *all* packages ILMerged their dependencies to keep this kind of carry-on to a minimum.
Having grappled for 5 hours trying to get Courier 2 and uCommerce to co-habitate, I thought I'd share my solution.
uCommerce and Courier 2 have 5 dlls with different versions in common:
They share other dlls that have the same version too, but they don't cause any issues.
My directory structure at build-time is as follows:
In web.config I added the following dependentAssembly entries (for some reason uCommerce seems to depend on version 1.0.1.0 of Iesi.Collections, which isn't distributed, but a redirect to the v2.1.2.4000 dll seems to work OK):
This text editor is awful! As a first-time poster, I'm seriously put-off. My ordered/unordered lists don't even show numbers/bullets!
Paul,
Your web.config entries above worked like a charm. One strange thing I noticed was that my Castle.Core assembly indicates version 2.5.2.0 instead of the above (2.5.1.0). I am using uCommerce 2.0.5.0. Strangely enough when I substitute 2.5.2.0 for the dependancy in web.config, I get errors. Somehow using 2.5.1.0 as you originally stated seems to work. Also noticed that the XSLT compile error states that it is looking for the 2.5.1.0 assembly even though the version that was downloaded with the package claims 2.5.2.0. Did you notice this issue as well?
Hi Phil,
Have you managed to get Courier and uCommerce both working at the same time? It's actually something I never managed, as there was an issue with the NHibernate dll that I couldn't work around. Essentially I was able to remove build errors by using the redirect, but a class or method that was being used in v2.1.2.400 wasn't present in v3.1.0.4000 - this meant that when the assembly was dynamically loaded, it blew up.
My solution in the end was to deploy two versions of Umbraco (using our own deployment framework) that both point at the same database. When they're deployed one gets the uCommerce dlls, and one gets the Courier dlls which means I can use both features from two different Umbraco instances. It smells, and I hate it, but it's the only solution I have found.
With regard to your question about 2.5.2.0 vs 2.5.1.0 - I noticed the same thing. Visual Studio reports the version as one thing, and Windows Explorer reports the other. Very strange!
Hope some of this helps you and I have saved you some of the pain I went through with this.
Paul
My other comment might be to warn you away from uCommerce, if you haven't yet got very far with it.
It's got one of the the most inpenetrable APIs known to man, and it's highly untestable without quite a bit of extra work.
Paul
To be perfectly honest with you, I have yet to build out uCommerce in any way. Like you I was scratching my head with the dependancy problems and had just figured out the five libraries needing attention when I came across your post. Courier seems to work OK. Have you looked at Tea Commerce yet? I'm just dipping my toe in the e-commerce world so I claim ignorance at this point. If uCommerce is that difficult to manipulate then maybe I should look for something else? My apologies for straying off topic of this thread.
Courier's OK (although it has it's own set of idiosyncracies), and I think is a different class of add-on to uCommerce.
We've persisted with uComnmerce as it was the only Umbraco eCommerce add-on that had some specific features. That said, it hasn't been an easy road. The documentation consists of a series of blog posts by the author. When I say the API is hard to work with, here's an example (off the top of my head - I could come up with at least 10 major flaws).
A concept in uCommerce is a catalogue. Catalogues have an Id (int) and a Name (string) - all very straightforward. Where it starts to get very frustrating is when the API exposes methods like GetCatalogueByName(string name). You pass this method your catalogue's name, and it blows up. At this point you'll probably open Reflector and look under the bonnet to see what's going on. The method will take your name (string) argument, cast it to an int, and perform a look-up by Id! Unbelievable! So your code ends up littered with comments about why you're doing what you're doing because it looks counter-intuitive to the uninitiated.
We spent some time evaluating the various options, and uCommerce was the option we chose. Whilst it will (eventually) be fit for purpose in that we'll be able to run an eCommerce section of our site, the implementation time will be something like 3-4 times longer than I expected.
Hope this helps,
Paul
Gotcha, Thanks for the "heads-up". I looked at my commerce options for Umbraco and this one stood out as the most complete. I'm only evaluating the free version at this point and as you can tell I haven't gotten very far with it. I stumbled across tea commerce today by mistake. It advertises to be simple but extendable. I use an Intuit payment gateway so I can't just grab any shopping cart and expect them to accept it. My hope would be that uCommerce was used widely enough for Intuit to give me the go-ahead. Have you communicated these bugs to the author? Like you, when I see Get...ByName, I expect to use a string value. Sounds like your beta testing for the uCommerce team. ;) No offense towards them, they have obviously put a lot of effort into their product.
We're compiling a list of feedback, which we'll be sending when we're done :)
Hi Paul,
I'm sorry to hear that your experience with uCommerce is so bad.
The example you mention is quite a boo boo on our part. The idea was to try and maintain backwards compatibility with existing sites and have the API handle both names and ids. In hindsight we probably should have added another API and be done with it.
That said we do try and fix any errors discovered and reported by partners and I would appreciate any feedback or bug reports you can supply us with. You speed the process along by sending the reports directly to my email at ssl AT ucommerce DOT dk. We typically have a very rapid turnaround on bug reports, so specific issues are ironed out and builds sent to testing as they are made.
This is the first I hear about the issue, so naturally I will look into it and add a fix to the next release.
We do try and cover our code base with unit tests, but typically focus on the complicated engine pieces. It might be high time we expand the tests for the surface API. Even with a large tests suite it's impossible to cover all scenarios, doubly so for an API type product in which the use cases wary wildly.
Regarding the incompatiblity between Courier and uCommerce dependencies I can assure you we're working on fixing it as the issue will only become more pronounced when Umbraco 5 ships. We held off on fixing it as there were talks in the Umbraco Code Team on building the plugin model so each plugin would be self-contained thus the issue would be taken care of. Unfortunately this piece did not make it into the Umbraco 5 core, so we're currently working on ways of fixing it ourselves.
is working on a reply...