Receiving an "Access Denied" error when calling RegisterTypeMapping

Mar 26, 2010 at 1:56 PM

Hello,

I have downloaded the SPG v2 Iteration Drop 12 and am trying to implement the ServiceLocator componant in a custom SP 2007 portal.  I found extensive instructions on how to install the two demo projects, but couldn't find the instructions on how to just implement the individual componants themselves.  So I'm thinking there's a good chance that this is a configuration issue.

 When I make the call, this.config.RegisterTypeMapping<IRegistryService, Client.RegistryClient>();, it throws an "Access Denied" error in the SPFarmPropertyBag Update() method.

private string appName = Assembly.GetExecutingAssembly().GetName().Name;
private IServiceLocator serviceLocator;
private IServiceLocatorConfig config;
private IRegistryService registry;

public RegisteredAppsWebpartFeature()
{
    this.serviceLocator = SharePointServiceLocator.Current;
    this.config = this.serviceLocator.GetInstance<IServiceLocatorConfig>();
}

[SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)]
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    this.config.RegisterTypeMapping<IRegistryService, Client.RegistryClient>();
    registry = this.serviceLocator.GetInstance<IRegistryService>();

    Application app = new Application()
    {
        ApplicationName = this.appName,
        ApplicationRoles = ConfigurationManager.AppSettings["DefaultADGroup"],
        DateCreated = DateTime.Now,
        DisplayName = "Registered Apps"
    };
    registry.AddApplication(app);
}
The SP portal's application pool is running with the Network Service account. I hope someone can help me on this one. If more information is needed, just ask.
Thanks!
Coordinator
Mar 26, 2010 at 5:29 PM

Hi,

First please use the released version for SPGv2, which is at www.microsoft.com/spg.  We did additional performance testing and some performance bug fixes on the released version.

It does look like your issue here is a permission issue. 

- What is the scope of the feature?  Since a type mapping is stored at the farm configuration level, and therefore affects all apps in the farm, I'd recommend deploying the type mapping setting as a farm scoped feature.

- While a farm scoped feature gets activated when installed, and therefore it doesn't much mattter if you take the action in activated or installed, as a practice I'd recommend taking configuration action that is not feature instance specific in the feature installed rather than the feature activated event.

Can you try these two changes and see if you continue to have the issue.

Mar 26, 2010 at 7:17 PM

Thanks for pointing me to the released code.  The scope for this feature is set to "Site".  I'm new to SharePoint development, so I was unaware that farm scoped features are activated when installed.  But this is good news for us, since that is what we kinda wanted in the first place (i.e. an automatically activated feature). I will make that change.

After moving the configuration action from the feature activated event, to the feature installed event, it started working correctly.

Thanks for your time!

Jan 27, 2011 at 2:49 PM

I'm gonna resurrect this thread. I notice ckeyser recommends adding type mappings in a farm scoped feature. Why in the SPG project PartnerPortal is this not the case? In that project there are type mappings being registered in a few different places.

Can anyone explain this?

Coordinator
Jan 27, 2011 at 3:27 PM

A couple of things:

It doesn't work in SP2010 - can't write to farm config from a content web.  Therefore can't do this in a site or web scoped feature in the featureactivated method.

Improved understanding of the issue.  The settings are stored at the farm level, therefore a farm scoped feature matches the "scope" of the storage.  Type mappings are intended to be used by different applications.  Managing at the farm scope makes the most sense.  Another viable option is to do this in the feature installed event of a web or site scoped feature.  Since the install actually occurs logically at the farm level, and because install runs outside of the content web, this is also a viable option.  I personally prefer decoupling the mapping and implementation of the reusable type from other types of assets like web parts, etc. 

 

Jan 27, 2011 at 3:31 PM

Thanks for your prompt reply.

It feels more natural to me to register them with a farm scoped feature. Think I'll do this from now on.