Re: Digest for umbraco-dev@googlegroups.com - 2 updates in 1 topic

[Rusty Swayne]

Thanks Shannon.

I had the handler assigned to ApplicationInitialized originally also wasn't working and was kicking the tires a bit before writing you back again.

Deleting the PluginCache folder in App_Data and recycling the application pool does resolve the classes and is what I was trying to convey in my last post.

Also tried adding two packages containing different classes that should resolve consecutively to see if the first would resolve on installation of the second - but it did not.

Sent from my iPhone

On Apr 22, 2014, at 3:26 AM, "umbra...@googlegroups.com" <umbra...@googlegroups.com> wrote:

  Today's topic summary

Group: http://groups.google.com/group/umbraco-dev/topics

• Resolution of objects using PluginManager in a Package [2 Updates]

 Resolution of objects using PluginManager in a Package

Rusty Swayne <ru...@mindfly.com> Apr 21 09:58AM -0700  

Yep - sorry Shannon. Serves me write trying to write something up at the
end of the day.
 
I have package (Merchello) installed in Umbraco which includes a little
ApplicationEventHandler class
 
public class GatewayResolutionApplicationEventListener : ApplicationEventHandler
{
protected override void ApplicationStarting(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
{
base.ApplicationStarting(umbracoApplication, applicationContext);

PaymentGatewayProviderResolver.Current = new PaymentGatewayProviderResolver(() => PluginManager.Current.ResolveTypes<PaymentGatewayProviderBase>());
TaxationGatewayProviderResolver.Current = new TaxationGatewayProviderResolver(() => PluginManager.Current.ResolveTypes<TaxationGatewayProviderBase>());
ShippingGatewayProviderResolver.Current = new ShippingGatewayProviderResolver(() => PluginManager.Current.ResolveTypes<ShippingGatewayProviderBase>());
}
 
}
 
 
The solvers are really basic sub classes of LazyManyObjectResolverBase
 
 
internal sealed class PaymentGatewayProviderResolver : LazyManyObjectsResolverBase<PaymentGatewayProviderResolver, PaymentGatewayProviderBase>
{
/// <summary>
/// Initializes a new instance of the <see cref="PaymentGatewayProviderResolver"/> with an intial list of PaymentGatewayProvider types
/// </summary>
/// <param name="providers">The list of PaymentGatewayProviders</param>
internal PaymentGatewayProviderResolver(Func<IEnumerable<Type>> providers)
: base(providers)
{ }

public IEnumerable<Type> ProviderTypes
{
get { return InstanceTypes; }
}

}
 
 
We want to be able to allow other package developers be able to build extensions to Merchello as Umbraco packages and add them to Umbraco via the standard Umbraco install process. If the package (the extension package) contains a binary with has a sub class of PaymentGatewayProviderBase for example, we are trying to get our resolvers identify the class and add it to our list of "Payment Providers". This works beautifully if we simply drop the DLL containing the class to be resolved into the bin file, but our resolvers fail to resolve the class if it is included in a package and added through Umbraco - albeit pulling the dll out of the bin directory and immediately dropping it back in does force the resolution.
 
 
Also, in my previous description, I eluded to restarting the application pool corrects the issue. This actually turns out not to be true. Restarting IIS does not do it either - we have to remove the DLL from the bin and drop it back in or delete the PluginCache and restart the application pool.
 
 
Is there a way to refresh the PluginCache?


 

Shannon Deminick <sdem...@gmail.com> Apr 21 04:57PM -0700  

Typically you should be creating your resolvers in the
ApplicationInitialized method, the ApplicationStarting method is used to
modify/replace resolvers before resolution is frozen and the
ApplicationStarted is used after resolution is frozen in order to return
item(s) from the resolvers.
See: http://our.umbraco.org/Documentation/Reference/Events/application-startup#UsingApplicationEventHandlertoregisterevents
 
I'm not sure if that will solve your problem though - which does seem like
an odd one since we restart the application pool and the whole application
when you install a package from within Umbraco and of course if there is a
DLL in the package it will automatically restart the app pool anyways. The
PluginCache is ignored when we detect a hash change between what was
previously in the /bin folder which has been working successfully since 6.x
for all package installs.
 
Let me know if creating your providers in ApplicationInitialized fixes
anything, otherwise we'll need to investigate why it's not picking up the
types in the installed package. There's a folder: ~/App_Data/PluginCache
that contains two files, one which is the calculated hash and the other is
the cached types found. Before you install your package you can check what
the hash is in the hash file and then check that it has changed after you
install. You can also inspect the cache file to see what's been found.


 

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umbraco-dev...@googlegroups.com.
To post to this group, send email to umbra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/umbraco-dev/001a11c2f476b6096b04f79f0d97%40google.com.
For more options, visit https://groups.google.com/d/optout.