I have trying to upgrade from v3.5 to 3.6.0.13142 ... I have run the site and now get the following YSOD
Could not load file or assembly 'NHibernate, Version=3.1.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have also noticed in my web.config that the following line is wrong
I've had this before with another project. UCommerce now uses it's own mapped versions of the DLLs.
Soren will be able to fill you in more but if you drop in the NHibernate DLL into your bin folder (I think the on in the UC folder in the bin works) it should sort it, if not get the right one from an older install.
Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This is a bit crazy :( ... Surely upgrading should be easier than this.
I have copied the dll's from the bin/ucommerce folder into the main bin, but I get the log4net error??
Server Error in '/' Application.
Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Could you replace the log4net.dll in /bin with the default from Umbraco?
There are a number of different log4net.dlls in circulation, different versions, ones with public key token, and ones without. You'll need version 1.2.11.0 without public key token.
Could not load file or assembly 'NHibernate, Version=3.1.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I don't have a 3.1.0.4000 version anywhere? The one in the bin and the ones referenced in my projects are 3.3.3.4000 which is what came with uCommerce?
Yes. I removed that dll, but now I have an error with previously working code...
Specified method is not supported.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NotSupportedException: Specified method is not supported.
Source Error:
Line 50: {
Line 51: var currentCatalog = SiteContext.Current.CatalogContext.CurrentCatalog;
Line 52: var featuredCategories = Category.All().FetchMany(x => x.CategoryProperties)
Line 53: .Where(x => x.DisplayOnSite &&
Line 54: x.CategoryProperties.Any(y => y.DefinitionField.Name == "ShowOnHomepage" &&
It's throwing an error on the following line
var featuredCategories = Category.All().FetchMany(x => x.CategoryProperties)
As above. This site has been running fine all day. I just decided to 'try' and upgrade. Here is the full method (There are no errors in the editor either? So the code according to the intellisense is valid too)
Nope. That query DID run fine as it was. It seems the problem is this part
.FetchMany(x => x.CategoryProperties)
??? Why would this not work now ??? This is now also raising my previous concern even more, as to how inefficient the ucommerce API's are and they are certainly not 'Enterprise' level. See the thread below.
The LINQ APIs are there to enable a high degree of flexibility in querying. The flexbility does come at a cost of requiring the developer to be specific as to which information to bring back when querying.
uCommerce cannot know in advance which information you need thus relies on you to tell it using the Fetch() and FetchMany() methods. This is the way the underlying ORM work and is true for all ORM implementation whether from Microsoft or third parties. This is the same as what you'd do with no ORM in place: Bring back the full dataset that you require by specifying a JOIN between the tables you'd like to get back.
I believe the query in question will work given the small outlined update I provided before. I will also answer in more detail in the linked thread.
The underlying issue here is the disconnect between the relational model in the database and the object model of the app. It's well-known challenge in computer science and has in fact given rise to the popularity of NoSQL in general and document databases in particular, which do not exhibit this particular behavior due to design paradigm they're built on.
Ted Neward discusses this topic in detail in his post The Vietnam of Computer Science back in 2006. In short ORMs are not the best way of dealing with this, but it is the only way if we also want to provide flexiblity in querying and an automatic way of providing object oriented results from queries.
The alternative is to have fixed APIs with limited flexiblity (which incidently is what the Library APIs do).
We're trying to give you the best of both worlds: Full flexibility and query freedom with the LINQ API at the expense of requiring the developer to know how to handle the flexibility and the fixed nature API of the libraries, which get the job done quickly and easily, but don't offer flexibility for all situations.
The change you suggested doesn't work. As above, as soon as I put Fetch() or FetchMany() into my query WITHOUT a where clause it fails.... And as above. This is a working site. That query has been used, exactly as I posted for the past 4 months. But the issue now, is Fetch() & FetchMany() just don't seem to be working now at all.
I'm going to try upgrading to v4 now, and see it that update brings the functionality back.
Warning. Rant Ahead.
You as a person are a top chap and you always help when you are about (Like now), and I understand your situation about why the querying creates bad SQL, BUT you are pushing uCommerce as a paid 'Enterprise' level product along with showing the API as the way to use the product?
When in fact, using the API (As you know) creates insanely inefficient queries for ANYONE trying to use uCommerce in a busy environment with 10,000's+ of products and 1000's of categories (All with custom properties, which everyone has). They WILL end up in the same situation of a website that just hangs, or grinds to a halt and falls over under medium/heavy load.
Remember this is a paid product (And in my opinion) a very expensive product for what you actually get. You are targeting people trying to implement an 'Enterprise' level store. But your documentation is unbelievably poor, it's just a long list of links to old (mostly out of date) blog posts? Yet, this just isn't being addressed?
And where in the documentation does it cover situations like my other thread? Showing examples of how to query the data efficiently? It's a pretty standard thing wanting to bring back a set of products or categories based on the values of a property (AND I won't even start on trying to page those results!). Seriously, this is basic stuff from building an eCommerce site perspective. I can't believe I am the only person to bring this up.
Also I now realise I'm going to have to use HQL to do it, but it would be nice to have some real docs from a PAID, ENTERPRISE level product on how to do it - With simple examples of usage using HQL including what it is etc...
AND you should make people aware of this up front. That in fact, they are going to have to write their own SQL/HQL to query the database/learn your database structure if they want to query the products and categories properly/efficiently or have a large amount of products.
Honestly, I know I'm ranting. But I'm just being honest. And if I had known what I know now, I am 99% sure I wouldn't have gone down the uCommerce route. But I have spent so much money and time, that I have to keep going at present.
Fetch() AND FetchMany() DO NOT work now. I have managed to get v4 running. But your query example and in fact any query that tries to use Fetch() or FetchMany() just returns the following error.
Server Error in '/' Application.
Specified method is not supported.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NotSupportedException: Specified method is not supported.
The only way to make it run is to remove any reference to Fetch() or FetchMany() from all my queries?
Upon furter investigation it turns out that the updated NHibernate provider did not like the fact that Fetch and FetchMany are called before the Where clause. So the order has to be
Lee, I know it's frustrating and I your comments ring true.
First let me start out by saying that I failed on the communication of NHibernate sitting under the APIs. I felt that NHibernate is known and well-documented quantity and thus I didn't feel we could add anything beyond what's already out there.That was not the correct decision and I'm going to work to change that. In building as much flexibility and as many features into uCommerce we have failed to keep up with the documentation both on the query API and on the overall API.
I have failed in making it obvious that the underlying query engine of uCommerce is in fact based on NHibernate making it harder to know where to go and look for information.
The good news is that it's going to change rapidly in the coming months: We haven't announced this broadly yet, but I'm happy to tell you that we have secured venture funding for the company and the product so I have been able to bring on a number of new devs and related staff on board.
There's already a dev phase planned to focus on these types of things between the bigger development efforts, which will focus on:
Improvements on day to day features in the core platform
A full docs site to replace the existing blog/API reference sites
Updating existing docs to match with the current versions of the platform
A finally more docs to further explain the APIs in detail
Basically we can get a lot more stuff done going forward with more people and more competencies on the team both in dev, ops, and business.
Error While Upgrading
I have trying to upgrade from v3.5 to 3.6.0.13142 ... I have run the site and now get the following YSOD
I have also noticed in my web.config that the following line is wrong
It cannot find the type 'NHibernate.Caches.SysCache.SysCacheSectionHandler' ... Starting to wish I had just left it be now lol.
I've had this before with another project. UCommerce now uses it's own mapped versions of the DLLs.
Soren will be able to fill you in more but if you drop in the NHibernate DLL into your bin folder (I think the on in the UC folder in the bin works) it should sort it, if not get the right one from an older install.
Tim
Do you have a /bin/uCommerce folder? NHibernate DLLs in there?
Does Web.config contain<dependentAssembly> Elements with reference for NHibernate?
Ok managed to do that. Now in log4net hell??
This is a bit crazy :( ... Surely upgrading should be easier than this.
Yes there is a ucommerce folder in my bin file? And yes I have this in my web.config
I have copied the dll's from the bin/ucommerce folder into the main bin, but I get the log4net error??
Could you replace the log4net.dll in /bin with the default from Umbraco?
There are a number of different log4net.dlls in circulation, different versions, ones with public key token, and ones without. You'll need version 1.2.11.0 without public key token.
Done that. Now back with an nHibernate error
I don't have a 3.1.0.4000 version anywhere? The one in the bin and the ones referenced in my projects are 3.3.3.4000 which is what came with uCommerce?
What's the version of the UCommerce.dll? 3.6?
v3.6.0.13142
Any chance there's a NHibernate.ByteCode.Castle.dll in your /bin?
If there is try and get rid of it.
In the error above is mentions publicKey token 'aa95f207798dfdb4' which is in the web.config at this line?
But I have no idea why its saying 3.1.0.4000
Any chance there's a NHibernate.ByteCode.Castle.dll in your /bin?
If there is try and get rid of it.
Ahhh my reply didn't get added!!
Yes. I removed that dll, but now I have an error with previously working code...
It's throwing an error on the following line
As above. This site has been running fine all day. I just decided to 'try' and upgrade. Here is the full method (There are no errors in the editor either? So the code according to the intellisense is valid too)
Now we're getting somewhere.
Where's the code running? Directly in a Razor macro or in a compiled DLL?
Compiled DLL... It's something to do with the Where() it doesn't like for some reason... I removed the where clause and the site loaded.
So I trimmed it down to just
And I still the error?
I think it's because of the brackets. I moved one right after == "True". The statement below will run sans my comments of course :).
Nope. That query DID run fine as it was. It seems the problem is this part
??? Why would this not work now ??? This is now also raising my previous concern even more, as to how inefficient the ucommerce API's are and they are certainly not 'Enterprise' level. See the thread below.
http://our.umbraco.org/projects/website-utilities/ucommerce/ucommerce-support/44998-Query-ProductsCategories-By-Custom-Properties-Efficiently
Hi Lee,
The LINQ APIs are there to enable a high degree of flexibility in querying. The flexbility does come at a cost of requiring the developer to be specific as to which information to bring back when querying.
uCommerce cannot know in advance which information you need thus relies on you to tell it using the Fetch() and FetchMany() methods. This is the way the underlying ORM work and is true for all ORM implementation whether from Microsoft or third parties. This is the same as what you'd do with no ORM in place: Bring back the full dataset that you require by specifying a JOIN between the tables you'd like to get back.
I believe the query in question will work given the small outlined update I provided before. I will also answer in more detail in the linked thread.
The underlying issue here is the disconnect between the relational model in the database and the object model of the app. It's well-known challenge in computer science and has in fact given rise to the popularity of NoSQL in general and document databases in particular, which do not exhibit this particular behavior due to design paradigm they're built on.
Ted Neward discusses this topic in detail in his post The Vietnam of Computer Science back in 2006. In short ORMs are not the best way of dealing with this, but it is the only way if we also want to provide flexiblity in querying and an automatic way of providing object oriented results from queries.
The alternative is to have fixed APIs with limited flexiblity (which incidently is what the Library APIs do).
We're trying to give you the best of both worlds: Full flexibility and query freedom with the LINQ API at the expense of requiring the developer to know how to handle the flexibility and the fixed nature API of the libraries, which get the job done quickly and easily, but don't offer flexibility for all situations.
The change you suggested doesn't work. As above, as soon as I put Fetch() or FetchMany() into my query WITHOUT a where clause it fails.... And as above. This is a working site. That query has been used, exactly as I posted for the past 4 months. But the issue now, is Fetch() & FetchMany() just don't seem to be working now at all.
I'm going to try upgrading to v4 now, and see it that update brings the functionality back.
Warning. Rant Ahead.
You as a person are a top chap and you always help when you are about (Like now), and I understand your situation about why the querying creates bad SQL, BUT you are pushing uCommerce as a paid 'Enterprise' level product along with showing the API as the way to use the product?
When in fact, using the API (As you know) creates insanely inefficient queries for ANYONE trying to use uCommerce in a busy environment with 10,000's+ of products and 1000's of categories (All with custom properties, which everyone has). They WILL end up in the same situation of a website that just hangs, or grinds to a halt and falls over under medium/heavy load.
Remember this is a paid product (And in my opinion) a very expensive product for what you actually get. You are targeting people trying to implement an 'Enterprise' level store. But your documentation is unbelievably poor, it's just a long list of links to old (mostly out of date) blog posts? Yet, this just isn't being addressed?
And where in the documentation does it cover situations like my other thread? Showing examples of how to query the data efficiently? It's a pretty standard thing wanting to bring back a set of products or categories based on the values of a property (AND I won't even start on trying to page those results!). Seriously, this is basic stuff from building an eCommerce site perspective. I can't believe I am the only person to bring this up.
Also I now realise I'm going to have to use HQL to do it, but it would be nice to have some real docs from a PAID, ENTERPRISE level product on how to do it - With simple examples of usage using HQL including what it is etc...
AND you should make people aware of this up front. That in fact, they are going to have to write their own SQL/HQL to query the database/learn your database structure if they want to query the products and categories properly/efficiently or have a large amount of products.
Honestly, I know I'm ranting. But I'm just being honest. And if I had known what I know now, I am 99% sure I wouldn't have gone down the uCommerce route. But I have spent so much money and time, that I have to keep going at present.
Just to clarify...
Fetch() AND FetchMany() DO NOT work now. I have managed to get v4 running. But your query example and in fact any query that tries to use Fetch() or FetchMany() just returns the following error.
The only way to make it run is to remove any reference to Fetch() or FetchMany() from all my queries?
As a follow-up:
Upon furter investigation it turns out that the updated NHibernate provider did not like the fact that Fetch and FetchMany are called before the Where clause. So the order has to be
query.Where(...).FetchMany(...) not query.FetchMany(...).Where(...)In the future we will take care to include notes on updated dependencies.
Lee, I know it's frustrating and I your comments ring true.
First let me start out by saying that I failed on the communication of NHibernate sitting under the APIs. I felt that NHibernate is known and well-documented quantity and thus I didn't feel we could add anything beyond what's already out there.That was not the correct decision and I'm going to work to change that. In building as much flexibility and as many features into uCommerce we have failed to keep up with the documentation both on the query API and on the overall API.
I have failed in making it obvious that the underlying query engine of uCommerce is in fact based on NHibernate making it harder to know where to go and look for information.
The good news is that it's going to change rapidly in the coming months: We haven't announced this broadly yet, but I'm happy to tell you that we have secured venture funding for the company and the product so I have been able to bring on a number of new devs and related staff on board.
There's already a dev phase planned to focus on these types of things between the bigger development efforts, which will focus on:
Basically we can get a lot more stuff done going forward with more people and more competencies on the team both in dev, ops, and business.
is working on a reply...