Installing Creative Website Starter (CWS) on V6 makes back office unoperable
I have a live Umbraco instance, which I have recently upgraded to V6.
In the back office (Developer/Packages/Umbraco Package Repository/Starter Kits), I could browse various starter kits. I chose the Creative Website Starter (CWS) and clicked "Install Package".
I then saw the stack trace pasted below. The only way I could get the back office working again was to FTP to the files on the server and physically delete the file Creative.Website.Starter.dll.
Should this have happened? If I were not skilled enough to know how to delete the DLL, what could I have done? Should the back office have even displayed CWS as an option to install? - it's not as if I uploaded a zip file I'd found elsewhere, this was completely "within" the back office as a user experience.
I think this would have put a lot of Newbies off Umbraco.
Stack trace below:
Server Error in '/' Application.
Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
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.TypeLoadException: Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[TypeLoadException: Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.]
However I will always advice that people test packages on their local machines before installing them in a live environment to avoid cases like the one you describe above. You can't just install a package and expect it to be compatible with the version of Umbraco you're using since packages are 3rd party and not something the core developers can control.
The website starter package was written for Umbraco 4 and since many things have changed in Umbraco since then there could easily be some incompabitibility between this package and V6 since you see this error.
Don't know if there could perhaps be made some kind of check against the dll's that a package contains to see if it's compatible somehow though?
Fair enough about installation on a live instance. Caveat Emptor and all that.
However, I was feeling "brave" in feeling able to do this as I hoped that the Umbraco platform was becoming more stable.
There are many people with WordPress sites that do not have local installations and don't have the technical skills to deal with the situation of installing a package that then takes out the ability to use the back office. They expect their CMS to "just work". If Umbraco is to compete with the other open source CMSs, it needs to be very robust.
Perhaps better exception handling is needed? Perhaps there could be some validation run on installation of a package to check for a list of things (like implementation of RenderJsDependencies) and to disable the package (with displayed reasons) if not. I certainly don't expect the back office to be taken down by unhandled exceptions.
Also, I accept that 3rd party packages are not the responsibility of the Core Team. However, maybe the core team should consider only showing packages in the repository that at least state compatibility with the user's current version - particularly after a major version upgrade? Or, if known issues are found with old packages, leaning on the 3rd party developers to update their documentation or even remove old packages. It's better to have fewer packages, that work well, than lots, that may not work.
I care enough to raise this post because I really like Umbraco and want it to succeed. I don't want people put off by bad initial experiences.
I agree that it would be nice if Umbraco could just handle this gracefully by making sure that incompatible packages will not be allowed to be installed. Maybe it's something that should be brought to the attention of the core team by creating a ticket on the issue tracker?
The less mistakes one can make the better - it would be nice to see fewer YSOD's indeed...and as you say people get a bad experience, which is a shame.
But never the less I would always make sure to have a backup somehow wether I'm upgrading wordpress and installing old packages or if I'm working with Umbraco or any other system. I just don't trust the system 100% no matter what the system is :)
Installing Creative Website Starter (CWS) on V6 makes back office unoperable
I have a live Umbraco instance, which I have recently upgraded to V6.
In the back office (Developer/Packages/Umbraco Package Repository/Starter Kits), I could browse various starter kits. I chose the Creative Website Starter (CWS) and clicked "Install Package".
I then saw the stack trace pasted below. The only way I could get the back office working again was to FTP to the files on the server and physically delete the file Creative.Website.Starter.dll.
Should this have happened? If I were not skilled enough to know how to delete the DLL, what could I have done? Should the back office have even displayed CWS as an option to install? - it's not as if I uploaded a zip file I'd found elsewhere, this was completely "within" the back office as a user experience.
I think this would have put a lot of Newbies off Umbraco.
Stack trace below:
Server Error in '/' Application.
Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
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.TypeLoadException: Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[TypeLoadException: Method 'RenderJsDependencies' in type 'Creative.Website.Starter.ClientDependency.Html5StandardRenderer' from assembly 'Creative.Website.Starter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.]
System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes) +0
System.Reflection.RuntimeAssembly.GetExportedTypes() +38
Umbraco.Core.TypeFinder.GetTypesWithFormattedException(Assembly a) +75
Umbraco.Core.TypeFinder.GetTypes(Type assignTypeFrom, IEnumerable`1 assemblies, Boolean onlyConcreteClasses) +134
Umbraco.Core.TypeFinder.GetAssignablesFromType(IEnumerable`1 assemblies, Boolean onlyConcreteClasses) +63
Umbraco.Core.TypeFinder.FindClassesOfType(IEnumerable`1 assemblies, Boolean onlyConcreteClasses) +59
umbraco.BusinessLogic.Actions.Action.ReRegisterActionsAndHandlers() +133
umbraco.BusinessLogic.Actions.Action..cctor() +114
[TypeInitializationException: The type initializer for 'umbraco.BusinessLogic.Actions.Action' threw an exception.]
umbraco.BusinessLogic.Actions.Action.GetJavaScriptFileReferences() +0
umbraco.cms.presentation._umbraco.RenderActionJS() +43
umbraco.cms.presentation._umbraco.Page_Load(Object sender, EventArgs e) +1815
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +14
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +35
System.Web.UI.Control.OnLoad(EventArgs e) +91
umbraco.BasePages.BasePage.OnLoad(EventArgs e) +14
System.Web.UI.Control.LoadRecursive() +74
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2207
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272
Hi Nick
I do understand your concern.
However I will always advice that people test packages on their local machines before installing them in a live environment to avoid cases like the one you describe above. You can't just install a package and expect it to be compatible with the version of Umbraco you're using since packages are 3rd party and not something the core developers can control.
The website starter package was written for Umbraco 4 and since many things have changed in Umbraco since then there could easily be some incompabitibility between this package and V6 since you see this error.
Don't know if there could perhaps be made some kind of check against the dll's that a package contains to see if it's compatible somehow though?
All the best,
Jan
Jan,
Fair enough about installation on a live instance. Caveat Emptor and all that.
However, I was feeling "brave" in feeling able to do this as I hoped that the Umbraco platform was becoming more stable.
There are many people with WordPress sites that do not have local installations and don't have the technical skills to deal with the situation of installing a package that then takes out the ability to use the back office. They expect their CMS to "just work". If Umbraco is to compete with the other open source CMSs, it needs to be very robust.
Perhaps better exception handling is needed? Perhaps there could be some validation run on installation of a package to check for a list of things (like implementation of RenderJsDependencies) and to disable the package (with displayed reasons) if not. I certainly don't expect the back office to be taken down by unhandled exceptions.
Also, I accept that 3rd party packages are not the responsibility of the Core Team. However, maybe the core team should consider only showing packages in the repository that at least state compatibility with the user's current version - particularly after a major version upgrade? Or, if known issues are found with old packages, leaning on the 3rd party developers to update their documentation or even remove old packages. It's better to have fewer packages, that work well, than lots, that may not work.
I care enough to raise this post because I really like Umbraco and want it to succeed. I don't want people put off by bad initial experiences.
Hi Nick
I agree that it would be nice if Umbraco could just handle this gracefully by making sure that incompatible packages will not be allowed to be installed. Maybe it's something that should be brought to the attention of the core team by creating a ticket on the issue tracker?
The less mistakes one can make the better - it would be nice to see fewer YSOD's indeed...and as you say people get a bad experience, which is a shame.
But never the less I would always make sure to have a backup somehow wether I'm upgrading wordpress and installing old packages or if I'm working with Umbraco or any other system. I just don't trust the system 100% no matter what the system is :)
/Jan
Hello
I am getting this error when trying to install CWS starter kit
Please help none of the kits are getting installed
is working on a reply...