2

I have a site collection scoped feature that should provision a css file to the "Style Library" of a site collection. The feature also performs cleanup of the file in the deactivation receiver.

I have experienced some problem with the blob cache of the web application storing the old file when I update it (deploy solution, reactivate feature etc). The file in the library is the correct one (proved by downloading it), but IE/Chrome/Firefox/Whatever receive the old version of the file.

Discovering after some lost hours the magic world of the blob cache, I have resort to a simple script like this:

$webApp = Get-SPWebApplication "<WebApplicationURL>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
Write-Host "Flushed the BLOB cache for:" $webApp

to flush the cache for the web application. No need to say, it magically start working again as expected.

So, to avoid this problem in the future, I was thinking to add a feature activated receiver to my code, and in it call the FlushBlobCache method.

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
        SPSite parentSite = ((SPSite)properties.Feature.Parent);

        Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache(parentSite.WebApplication);
}

Tested that, I receive an AcessViolationError.

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache(SPWebApplication webapplication)

Anyone know if what I am attempting to do is even possibile? Is that an effect of the dared sp2010 "RemoteAdministratorAccessDenied" security setting? Do I need to impersonate a specific user (was using the farm account, so I don't belive that's the problem - may give RunWithElevated a try) or it is simply impossible to do in a site collection feature?

UPDATE: Seems that all is caused by a nice snipet of code similar to this (reflector taken)

if (!webapp.Farm.CurrentUserIsAdministrator())
{
    throw new AccessViolationException();
}

So I suppose that this explain the error (won't ACCESS DENIED be a more accurate ex to throw????). So the new question is: has anyone tried this before and found an acceptable way to perform this operation?

Improve this question

1 Answer 1

Reset to default
1

It's heavyweight, but you might be able to do this with a timer job? You could try something like a Work Item Timer Job, which would let you raise jobs from within the site collections. But it is a pretty big solution element for such a small job.

Improve this answer
5
  • Interesting solution. But I'm not sure I have understood fully your advice: since the error seem to come from a check "webapp.Farm.CurrentUserIsAdministrator())", why would a Work Item Timer Job bypass the problem? From what I see the work item would execute in the site collection app pool, so the best we can hope to do is to "impersonate" the AppPool account. Why you belive it would help?
    – SPArcheon
    Nov 23, 2012 at 7:37
  • It doesn't run as the app pool. It runs as the account used by the OWSTimer service, which is normally highly privileged. Even then, I find that the timer service seems to be able to do things that I wouldn't expect to be able to do even with that account.
    – Andy Burns
    Nov 23, 2012 at 14:59
  • Yes, you are right - I was still thinking about the feature - the timer job runs under the owsTimer process (so, disregard the previous comment, don't know what I was thinking =_=). That said, I will have to test this - I have the suspect that the "CurrentUserIsAdministrator" method hides some logic that wouldn't work in a timer job. Let me check and we will see.
    – SPArcheon
    Nov 26, 2012 at 7:26
  • 1
    Still, like you say a similar approach seems to be the classical "cannonball to kill a mosquito". Which is just normal since we are talking about SharePoint.
    – SPArcheon
    Nov 26, 2012 at 7:28
  • see the updated question, the code fails because of an internal check "webapp.Farm.CurrentUserIsAdministrator()". So I don't belive it can work in a workflow. Still have to test it though, there may be some logic that disable that check.
    – SPArcheon
    Dec 7, 2012 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.