Deploy a web part to a page during feature activation within a Sandbox Solution

I've been hitting my head against a wall on this one for the last couple of days. I have a pretty simple requirement but I cant see how it can be achieved within a Sandboxed solution. I'm depressed because I think its a critical limitation that will cause me grief in future solutions too.

Here is the scenario.

I have an existing site and I want to be able to activate a feature, and then as part of that activation, drop web parts onto some specific pages. In my case I want to be able to drop it onto the "AllItems.aspx" page of a list, but I'm equally having trouble adding it to the default.aspx home page. I would be happy either way.

Note: I want to be able to activate this on existing site, I dont want to create a new Site Definition.

Here is what I have tried:

1. Feature Receiver: No go. You cant use the SPLimitedWebPartManager class, and the SPWebPartManager class works only within the context of the page where its instantiated. So bascially, you cant do this in code.

2. XML Module: I think this is the most likely path forward, however it seems to always want to provision a file to the site. For example, if I want to add a web part to the home page (default.aspx), then there doesn't seem to be a way to just get a reference to the page, it always wants to overwrite it with a new file. But I dont want to do that, I just want to add a Web Part to the existing page. See my elements XML below, I have tried various combinations of "IgnoreIfAlreadyExists" and removing the Path attribute, and setting it blank.

3. Delegate Control: Not allowed in the sandbox.

4. I actually want to be able to add a web part to the "AllItems.aspx" form of a list, so I also tried to add the web part via the SCHEMA.XML file as described here: Add Web Part through the SCHEMA.XML but this didn't wor开发者_高级运维k either. I should be able to do it by more heavily customising the List Definition, but that seems a little over the top and I'm reluctant to do that before ruling out the other options.

So, the only Neat way I can see through it is some sort of "Configuration" page, which then does it via the Web Services. But this is a pain, with the user having "Activate" the feature and then "Activate" again on my configuration page.

Anyway, it may just be that I'm missing something obvious. Been a while between XML fiddling on SharePoint for me, and this is my first Sandbox solution. Really hope someone else has cracked this nut.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="Pages">
    <File Path="" Url="default.aspx">
      <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
        <![CDATA[
              <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" xmlns:iwp="http://schemas.microsoft.com/WebPart/v2/Image">
                <Assembly>(Assembly), Version=1.0.0.0, Culture=neutral, PublicKeyToken=12baeb5f1600543c</Assembly>
                <TypeName>(Typename)</TypeName>
                <FrameType>None</FrameType>
                <Title>ListAnnouncement</Title>
              </WebPart>
            ]]>
      </AllUsersWebPart>
    </File>
</Module>
</Elements>

---

You can add web parts to existing pages using a full-trust proxy. To quote MSDN:

"Sandbox proxies are components that enable you to make full-trust functionality available to sandboxed solutions."

In a nutshell, you just need to create a seperate non-sandboxed assembly that contains methods to add web parts on a specified URL as per normal (i.e. using the SPLimitedWebPartManager class). You then reference and register this proxy assembly in your sandboxed solution -- not unlike consuming a web service really.

All is detailed here: How to: Create and Register a Sandbox Proxy

And here is someone who has already done it: Add Web Part Programmatically in Sandbox Environment

I'm trying to do this exact same thing in a sandbox solution that is to be deployed to SharePoint Online. This proves to be a little bit of a pickle because you can't scope features to the farm level -- but you shouldn't have this problem in an on-premise environment. Let me know how you get on...