Yes I'm aware that this is against a beta, but no time like the present to start looking at support ;)
So first off it does actually install into 7.0.0 beta, woo! It does throw a JS error once the install is finished, I think it's trying to reload the app list or something, I forgot to write it down.
Once you have it installed navigating to the app will see the tree fail with a YSOD:
Failed to retreive data for application tree teacommerce
Value cannot be null. Parameter name: context
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.ArgumentNullException: Value cannot be null. Parameter name: context
Stack Trace:
at Autofac.ResolutionExtensions.ResolveService(IComponentContext context, Service service, IEnumerable`1 parameters)
at Autofac.ResolutionExtensions.Resolve(IComponentContext context, Type serviceType, IEnumerable`1 parameters)
at Autofac.ResolutionExtensions.Resolve[TService](IComponentContext context, IEnumerable`1 parameters)
at Autofac.ResolutionExtensions.Resolve[TService](IComponentContext context)
at TeaCommerce.Api.Infrastructure.Security.PermissionService.get_Instance()
at TeaCommerce.Umbraco.Application.Trees.StoreTree.CreateRootNode(XmlTreeNode& rootNode)
at umbraco.cms.presentation.Trees.BaseTree.CreateRootNode()
at umbraco.cms.presentation.Trees.BaseTree.Initialize()
at umbraco.cms.presentation.Trees.BaseTree.get_RootNode()
at Umbraco.Web.Trees.ApplicationTreeExtensions.TryGetRootXmlNodeFromLegacyTree(ApplicationTree appTree, FormDataCollection formCollection, UrlHelper urlHelper)
at Umbraco.Web.Trees.ApplicationTreeExtensions.TryGetRootNodeFromLegacyTree(ApplicationTree appTree, FormDataCollection formCollection, UrlHelper urlHelper, String currentSection)
at Umbraco.Web.Trees.ApplicationTreeController.GetRootForMultipleAppTree(ApplicationTree configTree, FormDataCollection queryStrings)
at Umbraco.Web.Trees.ApplicationTreeController.GetApplicationTrees(String application, String tree, FormDataCollection queryStrings)
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass13.<GetExecutor>b__c(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.<>c__DisplayClass5.<ExecuteAsync>b__4()
at System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)
Since I don't have the source code I've been digging into it with ILSpy, it would seem that the problem is to do with how Autofac is configured. I'm more than happy to guineapig new builds/debug builds to get more diagnostic info.
I see the error is this: Could not load type 'umbraco.presentation.umbracobase.RestExtension' from assembly 'umbraco, Version=1.0.5032.23343, Culture=neutral, PublicKeyToken=null'.
That is properly because Tea Commerce is build using the Umbraco 4.7 dll files to support 4.7+. But some dll or namespaces has properly been removed in Umbraco 7. So now is the tricky question - what to do about that? Make Tea Commerce only compatible with Umbraco 7 or is it possible to build using different umbraco dll files? Or is there any charts about what Umbraco versions is used at the moment?
Ok, I see the problem, that was obsoleted at some point and there's a new attribute that people are intended to migrate to (and in 7.0 they are removing it all together).
So this raises a few questions:
How many versions back do you want to support?
Is it viable to have different downloads for v4.7 -> v6.x and v7.0+?
Now let's think about the first question, how many versions back do you want to support? By my investigation into the source the replacement way of doing Base came in to being during 4.10 (here's the first commit and that also includes a config change to go to 4.10). Now let's assume that it was 4.10.0 that it was first in the source, according to the current downloads list this was 4 releases since the last 4.7, 13 releases from the final 4.x release and 27 releases from the current stable (6.1.6). So the question is, do you want to be supporting a release that is at least 28 versions out of date? What features is Tea Commerce not able to leverage in Umbraco because you're aim is to have such a high level of backwards compatibility?
Onto the other question, do you want to have different download packages for the different versions of Umbraco (Belle and non-Belle). Chances are you're going to want to eventually, to ensure that the UI of Tea Commerce fits the appropriate version of Umbraco, but how do you address the codebase differences? One way to do that is to configure different builds in Visual Studio (Build -> Configuration Manager). In that you can then create a Umbraco 7 Debug/Release build which will then create new sections in the csproj file. You can then edit the csproj files and add new compiler flags! So this would mean you can do something like:
#if UMB7
[Umbraco.Web.BaseRest.RestExtension("TC")]
#else
[umbraco.presentation.umbracobase.RestExtension("TC")]
#endif
public class RestExtensions { //and so on
So then when you generate your release packages (how ever they are done) you just have it call the different MSBuild targets, spit out differently named packages and tell people to use the -Umbraco7 one if they are using Umbraco 7.
First thing is that we want to support 4.7+ because a lot of people don't update there Umbraco site when it works because of the update process is not always that easy as e.g. wordpress. So when we launch the marketing module we want to be able to support all previous installed Tea Commerce sites. And that could easily be an Umbraco 4.7+.
The compiler flags is an option. But as you say - in time the entire UI should proberly be converted to Belle. In 7.0 we will already need to have three new data types as the data types API has changed to be front end based. So how would we handle that we need to install different data types depending on the Umbraco version? AND if we think on the future - how would we handle the change of the entire UI, BUT still have a version that works for Umbraco 4.7+? Would it be best to have two different branches in source control? Because we would need a TeaCommerce.Umbraco.Application (the admin UI) VS project for both Umbraco 4.7+ and for Umbraco 7 - BUT they need to be implemented completely different - BUT it would be best to have the same namespace for both VS projects. Maybe two different VS solution files could do the trick.
So looking back into the release history of Umbraco 4.7 was released 18 months ago and it has a security vulnerability that wasn't eradicated until 4.11.9 (basically every release between those two points has a big red warning of "don't use!").
You say that you don't want to disadvantage users still on 4.7 (or well, anything prior to 4.10.0), do you have statistics on the number of users that are still on those versions? Do you have statistics as to whether they upgrade Tea Commerce? If upgrading Umbraco is "hard" then wouldn't upgrading Tea Commerce be an equally problematic affair?
More over from that the longer you stay with legacy (and keep in mind unsupported) versions the longer you hold back Tea Commerce itself. What if there's a new feature (in Umbraco) available that you want to leverage, say the new API layer in v6? How long do you put that off, 6 months after the feature is release, 12 months, 18 months? What's the impact on the competitiveness of your product in the market by maintaining such a long compatibility tail?
The following might be considered a tough stance but I've never been one to shy away from hard points :P.
When you're adding a new feature what are the reasons for it? To be more competitive in the market? That'd seem logical, but also to make more money. From looking at the Tea Commerce license it's a once-off purchase for your domain, so once you've got my money you're not getting more from me until I have a new domain. Now if I'm on 4.7.0 and I've got no interest in upgrading my site www.foobar.com beyond that Umbraco release does it make sense to target me as a core consumer? I don't think so, really all I'm doing is ticking along with my business getting free upgrades to my eCom platform while holding them back because I chose not to upgrade.
That doesn't seem like the best business strategy; sure you don't want to actively piss-off that customer base but at the same time I don't see anything wrong with saying "as of version v-Next you will require Umbraco x.y.z at a minimum".
I'll address your point about build-targets when I get some more time.
You are right. I think what we will do is to make the new features available in the Tea Commerce API and then seperate the Umbraco frontend and make one that works with Umbraco 7. Then when things omve forward on the Umbraco platform - I think we must just update and say that people have to update their Umbraco version to have the latest Tea Commerce. Just so we dont have too many different versions of the Umbraco code base that we need to support :)
Errors with 7.0.0 beta
Yes I'm aware that this is against a beta, but no time like the present to start looking at support ;)
So first off it does actually install into 7.0.0 beta, woo! It does throw a JS error once the install is finished, I think it's trying to reload the app list or something, I forgot to write it down.
Once you have it installed navigating to the app will see the tree fail with a YSOD:
Since I don't have the source code I've been digging into it with ILSpy, it would seem that the problem is to do with how Autofac is configured. I'm more than happy to guineapig new builds/debug builds to get more diagnostic info.
Environment info
Hi Aron
I see the error is this:
Could not load type 'umbraco.presentation.umbracobase.RestExtension' from assembly 'umbraco, Version=1.0.5032.23343, Culture=neutral, PublicKeyToken=null'.
That is properly because Tea Commerce is build using the Umbraco 4.7 dll files to support 4.7+. But some dll or namespaces has properly been removed in Umbraco 7. So now is the tricky question - what to do about that? Make Tea Commerce only compatible with Umbraco 7 or is it possible to build using different umbraco dll files? Or is there any charts about what Umbraco versions is used at the moment?
Kind regards
Anders
Ok, I see the problem, that was obsoleted at some point and there's a new attribute that people are intended to migrate to (and in 7.0 they are removing it all together).
So this raises a few questions:
Now let's think about the first question, how many versions back do you want to support? By my investigation into the source the replacement way of doing
Basecame in to being during4.10(here's the first commit and that also includes a config change to go to4.10). Now let's assume that it was4.10.0that it was first in the source, according to the current downloads list this was 4 releases since the last4.7, 13 releases from the final4.xrelease and 27 releases from the current stable (6.1.6). So the question is, do you want to be supporting a release that is at least 28 versions out of date? What features is Tea Commerce not able to leverage in Umbraco because you're aim is to have such a high level of backwards compatibility?Onto the other question, do you want to have different download packages for the different versions of Umbraco (Belle and non-Belle). Chances are you're going to want to eventually, to ensure that the UI of Tea Commerce fits the appropriate version of Umbraco, but how do you address the codebase differences? One way to do that is to configure different builds in Visual Studio (
Build->Configuration Manager). In that you can then create a Umbraco 7 Debug/Release build which will then create new sections in thecsprojfile. You can then edit thecsprojfiles and add new compiler flags! So this would mean you can do something like:So then when you generate your release packages (how ever they are done) you just have it call the different MSBuild targets, spit out differently named packages and tell people to use the
-Umbraco7one if they are using Umbraco 7.Does that make sense?
First thing is that we want to support 4.7+ because a lot of people don't update there Umbraco site when it works because of the update process is not always that easy as e.g. wordpress. So when we launch the marketing module we want to be able to support all previous installed Tea Commerce sites. And that could easily be an Umbraco 4.7+.
The compiler flags is an option. But as you say - in time the entire UI should proberly be converted to Belle. In 7.0 we will already need to have three new data types as the data types API has changed to be front end based. So how would we handle that we need to install different data types depending on the Umbraco version? AND if we think on the future - how would we handle the change of the entire UI, BUT still have a version that works for Umbraco 4.7+? Would it be best to have two different branches in source control? Because we would need a TeaCommerce.Umbraco.Application (the admin UI) VS project for both Umbraco 4.7+ and for Umbraco 7 - BUT they need to be implemented completely different - BUT it would be best to have the same namespace for both VS projects. Maybe two different VS solution files could do the trick.
What are your thoughts?
Kind regards
Anders
So looking back into the release history of Umbraco 4.7 was released 18 months ago and it has a security vulnerability that wasn't eradicated until
4.11.9(basically every release between those two points has a big red warning of "don't use!").You say that you don't want to disadvantage users still on
4.7(or well, anything prior to4.10.0), do you have statistics on the number of users that are still on those versions? Do you have statistics as to whether they upgrade Tea Commerce? If upgrading Umbraco is "hard" then wouldn't upgrading Tea Commerce be an equally problematic affair?More over from that the longer you stay with legacy (and keep in mind unsupported) versions the longer you hold back Tea Commerce itself. What if there's a new feature (in Umbraco) available that you want to leverage, say the new API layer in v6? How long do you put that off, 6 months after the feature is release, 12 months, 18 months? What's the impact on the competitiveness of your product in the market by maintaining such a long compatibility tail?
The following might be considered a tough stance but I've never been one to shy away from hard points :P.
When you're adding a new feature what are the reasons for it? To be more competitive in the market? That'd seem logical, but also to make more money. From looking at the Tea Commerce license it's a once-off purchase for your domain, so once you've got my money you're not getting more from me until I have a new domain. Now if I'm on
4.7.0and I've got no interest in upgrading my site www.foobar.com beyond that Umbraco release does it make sense to target me as a core consumer? I don't think so, really all I'm doing is ticking along with my business getting free upgrades to my eCom platform while holding them back because I chose not to upgrade.That doesn't seem like the best business strategy; sure you don't want to actively piss-off that customer base but at the same time I don't see anything wrong with saying "as of version v-Next you will require Umbraco x.y.z at a minimum".
I'll address your point about build-targets when I get some more time.
You are right. I think what we will do is to make the new features available in the Tea Commerce API and then seperate the Umbraco frontend and make one that works with Umbraco 7. Then when things omve forward on the Umbraco platform - I think we must just update and say that people have to update their Umbraco version to have the latest Tea Commerce. Just so we dont have too many different versions of the Umbraco code base that we need to support :)
Kind regards
Anders
is working on a reply...