I am afraid that your approach to run a task in the background is not possible. I can confirm that you cannot access the SP OM in an asynchronous delegate or run on a separated thread. I guess it is because the resource usage in sandboxed solutions is monitored and throttled. For example, you are not allowed to leave objects without disposing them too.
Not only you are disallowed to create an SPSite
object with either string
or Guid
; you cannot pass the (SPSite)properties.Feature.Parent
object that is available in the event receiver to the delegate too. (All properties of the object will throw the same exception.)
Generally I think that your solution would be too fragile. In a traditional solution, your code would be running in the w3wp.exe
process and the first application pool recycle after activating your feature would kill the timer (with the entire application domain). Similarly, in a sandboxed solution you would be at the mercy of SPUCWorkerProcess.exe
. You need some service host that will execute your code every day reliably.
Sandboxed solutions and/or SharePoint Online do not offer functionality for background-running services. You would have to run your code somewhere else, for example:
If you are allowed to deploy at least a small farm solution you can deploy the list item updating code as a SP timer job.
If you can afford running a Windows machine all the time you can write the list item refreshing code using the SP Client OM and install either as a Windows Service (timer loop) or as a Windows Scheduled Task (timed start). (The latter is simpler.)
If your solution is supposed to run in SharePoint Online and you cannot rely on a local Windows machine you can deploy it as a hosted service (Worker Role) in Microsoft Azure.
You can implement the regular updating functionality to run on demand in the sandboxed solution - as an ASPX page, for example. Then you would trigger the URL of the resource executing the code by public services like pingler or webcron.
Actually, the options 1 - 3 can be written the same way as the option 4 - the code to execute regularly within the sandboxed solution and the triggering code (very short and SP-independent) separately according to the scheduler's nature - it can be even a perl script using LWP scheduled by cron.
--- Ferda