We have moved to GitHub Issues
Created by Matt Brailsford 30 Apr 2014, 12:07:02 Updated by Rusty Swayne 12 May 2014, 18:58:04
Some users of Vorto have reported that the property editor doesn't show up when they install the package, even after restarting the app pool. It turns out that the PropertyEditor (which is defined in code) doesn't get added to the PluginCache so it doesn't show up until the cache is cleared.
Can we update the installer so that it handles code defined PropertyEditors?
That might explain several reports of the Image Cropper not showing up on v7.0 to v7.1 upgrades also.
by 'Defined in code' do you mean inside a DLL or inside of App_Code ?
The PluginCache creates a combined hash of:
For each file, the file name, the creation date/time and the last written date/time are taken into account to create the hash. For the trees.config file, the content of the file is also taken into account.
When we detect that this combined hash has changed we will re-scan all plugins found in the DLLs and then rewrite the plugin list and the new hash.
This has been working like this for many many versions including many 6.x versions and hasn't changed. Any chance you can replicate this issue or does it occur randomly?
I'm not sure if this would help, but it can't hurt is that when creating this hash we can take into account the number of files at all levels in these folders too but that seems like clutching at straws for a solution.
Anyways, let me know if you can replicate.
I wonder if this is related to this: U4-3505
How is your property editor defined (i.e. what class does it inherit from) ?
Sure, so it's in a DLL - so the hash should get updated with any DLL additions or updates in the /bin folder, this has been working for well over a year so seems odd. If we can replicate that would be great, or if we can get hold of a log file for an install that has just seen this issue that might help too.
The issue we encountered was when you installed a package that a DLL (with
PropertyEditor class). Subsequent app restarts don't do anything. However if/when we make a manual change to the /bin folder, then the PropertyEditor (in DLL) works as expected.
Not sure if this helps?
@Swayne is apparently having this issue with Merchello but this seems ultra strange since however you copy a DLL to the bin folder whether it's via the installer or not will trigger an app restart and the hash should change.
Does that happen each time?
Yes, it only happened when a package was installed for the first time.
@matt Can you confirm this?
I just experience this issue with a XSLT extension, I installed this http://our.umbraco.org/projects/website-utilities/exslt-redux checked my plugincache .list file, no sign of it and it didn't appear in the UI. Stopping and starting the app pool didn't help, so I deleted my PluginCache folder and contents and started up, now the extension is in the .list file and work fine in the UI.
Rusty mentioned he was having some problems with his own resolvers and said as soon as he stopped using the LazyManyObjectsResolverBase and instead just used the ManyObjectsResolverBase the issue went away. So potentially that gives me something more concrete to look at. Will test a few things this week.
Ok, I've figured this one out....
Here's the deal with LazyManyObjectsResolverBase - it is lazy which means it's not gonna go look up the plugins until they are needed. So your plugincache.list file will not be populated on app restart, it will get updated with the xslt extensions when they are used, like when executing XSLT.
So after installing exslt-redux you won't see the new plugins in that file, you will see them once you use XSLT since it will then need to load in the extensions.
BUT... and here's where things get funny... If you install the package:
Pretty sure i can easily fix this by just deleting the plugin list file when we detect that the hash has changed during startup, then it will force rescanning for those particular plugins because they aren't in the file.
Fixes this in : b048341da02523d27f5d4dd7ba33b1e9373ebf68
@Shandem I think your solution is spot on. In our implementation, we would have always had at least one object resolved since Merchello included some defaults during our installation. In our case, it also makes sense not to use the LazyManyObjectsResolverBase since we do need the values soon after the Umbraco application is started. Nice work!
Assignee: Shannon Deminick
Backwards Compatible: True
Affected versions: 7.1.1
Due in version: 7.1.3, 6.2.1