U4-4789 - PluginCache doesn't update with code defined PropertyEditors in package

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?



Jeavon Leopold 30 Apr 2014, 19:08:11

That might explain several reports of the Image Cropper not showing up on v7.0 to v7.1 upgrades also.

Shannon Deminick 01 May 2014, 05:03:01

by 'Defined in code' do you mean inside a DLL or inside of App_Code ?

Shannon Deminick 01 May 2014, 05:12:54

The PluginCache creates a combined hash of:

  • All files at all levels in the /bin folder
  • All files at all levels in the /App_Code folder
  • The global.asax file
  • the /Config/trees.config file

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.

Shannon Deminick 01 May 2014, 05:19:07

I wonder if this is related to this: U4-3505

How is your property editor defined (i.e. what class does it inherit from) ?

Sebastiaan Janssen 01 May 2014, 07:24:13

@Shandem https://github.com/mattbrailsford/Vorto/blob/master/Src/Our.Umbraco.Vorto/Web/PropertyEditors/VortoPropertyEditor.cs

Shannon Deminick 01 May 2014, 07:28:31

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.

Lee Kelleher 01 May 2014, 08:45:04

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?

Shannon Deminick 01 May 2014, 08:47:55

@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?

Lee Kelleher 01 May 2014, 08:52:26

Yes, it only happened when a package was installed for the first time.

@matt Can you confirm this?

Jeavon Leopold 08 May 2014, 16:36:51

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.

Shannon Deminick 12 May 2014, 05:19:20

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.

Shannon Deminick 12 May 2014, 06:37:35

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:

  • We detect that DLLs (etc) have changed, we write out a hash of your current app state
  • When we load in the plugins, we check if this is a newly changed hash, if it is then we re-scan for plugins and write to the cache list file. Otherwise we just load what was already found from the cache list file
  • Let's then say that you install the package, it writes a new hash but you don't use xslt so it doesn't scan for the plugins, then your app restarts again. No changes are detected so the hash doesn't change and therefore the app thinks all plugins have been resolved. Then you load xslt and it will just load what it had in there previously.

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.

Shannon Deminick 12 May 2014, 07:05:27

Fixes this in : b048341da02523d27f5d4dd7ba33b1e9373ebf68

Rusty Swayne 12 May 2014, 18:58:04

@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!

Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.1.1

Due in version: 7.1.3, 6.2.1


Story Points: