Categories

Awarded:

MVP Logo

» link

Hosted By:

You can deploy WebParts as Sandboxed solutions .. but ..

Posted on 12/4/2009 @ 12:09 AM in #SharePoint by | 11 comments | 1109 views

You can deploy WebParts as Sandboxed solutions .. but .. there are some restrictions on what that webpart can or cannot do.

  1. It has to be an ASPNET WebPart, not a Microsoft.SharePoint.WebPartPages.WebPart webpart.
  2. WebPart connections are not supported in Sandboxed solutions
  3. Sandboxed solutions webparts cannot access certain complex properties in the object model
  4. Any script in a sandboxed solution must be registered with the ScriptManager class
  5. Asynchronous postbacks won’t work.
  6. Since webpart solutions include an assembly, they must be deployed by a site collection administrator.

On 12/4/2009 12:13:59 AM Bil Simser said ..
Yeah, let me rush out to build this. NOT!


On 12/4/2009 10:35:32 AM Sahil Malik said ..
Hey Bil - Man tell u what, SP2010 feels way more solid than SP2007 ever did. Just being honest here. And you know me quite well that I don't hold back words. When something sucks, I say so. Sure there are still challenges with the platform, but for the manageability of Sandbox solutions, I am more than happy to live with the above restrictions. Also, reasonable workarounds can be made for many of those restrictions.


On 12/4/2009 11:01:45 AM Jaap Vossers said ..
The main problem I have with Sandboxed Solutions, is that DelegateControl customisation Features seem to be unsupported (from what I have seen)!

How am I supposed to reference a .js file on every page in the site collection, if I can't add anything to the AdditionalPageHead DelegateControl via a Feature? Do I really need to use a Farm Solution purely for this?


On 12/4/2009 11:32:10 AM Sahil Malik said ..
Jaap - COMPLETELY AGREED! You can do ScriptManager though, but still it's not the best situation. There are some other limitations as well, such as the restrictions on asynch postbacks. I am sure MSFT had a good reason to block that .. but I'd like to know what that good reason was :)

S


On 12/5/2009 11:39:31 AM mostafa said ..
Interesting... i can live with these restrictions, but as a developer i can't do Rich WP without Asynch postback event....i think there is a reason behind this ? let us know when you know why ?


On 12/6/2009 11:03:53 AM Jaap Vossers said ..
Sahil,

From where do you call into the ScriptManager? From that custom WebControl which you also can't add using a DelegateControl customisation? :)

I think the reason why it is not supported, is because of history. DelegateControl customizations are not stored in the db AFAIK, same for like CustomActions (don't know why though!). They are read from the filesystem. Sandboxed solutions don't allow access to the filesystem.

MS could have added support to programmatically add and persist DelegateControl customizations in the db using the API IMO.

Jaap


On 12/6/2009 2:37:37 PM Sahil Malik said ..
Jaap -

You can call the ScriptManager from code behind, or the webpart code itself (C# part).

S


On 12/6/2009 7:28:24 PM Jaap Vossers said ..
Yes you can, but it will only affect those pages that contains this web part.

I am talking about "global" solutions that consist of a single .js file which needs to be referenced on every single page in the site collection, which can be done using DelegateControl customization Feature.


On 12/6/2009 9:22:59 PM Sahil Malik said ..
Yep, there's no global solution! I think Nick Swan blogged about another approach here.

http://www.lightningtools.com/blog/archive/2009/12/06/add-javascript-files-once-to-a-page---sharepoint-sandbox.aspx

What do you think of that?

S


On 12/7/2009 5:59:53 AM Jaap Vossers said ..
that's an interesting post, but it solves a whole different issue.

I am disappointed about the lack of DelegateControl customization support in Sandboxed solutions, because I expected that I could distribute my recently published CodePlex project (http://devdashvis.codeplex.com/) as a Sandboxed solution. It consists of only a set of .js files that should be referenced on every page in the site collection. Unfortunately, I was forced to wrap it in a Farm solution.

I think there will be many more js-only solutions in the future, in particular because of the Client OM and REST, and they will all be affected by this limitation.

An alternative approach, which is very innovative, but isn't very clean IMO, is to do something like what Jan Tielens is doing with his jQueryLoader. He created an installer aspx page with inline javascript, which needs to be deployed into the site collection. This page uses the web services to get the contents of the master page, manipulates it with javascript string processing, and then saves it back using the web services. As I said, it works, but I would really prefer a more unobstrusive method.


On 8/19/2010 5:12:16 PM Jaap Vossers said ..
Apparently it CAN be done using CustomAction, which is supported in Sandbox Solutions! :)

http://weblogs.asp.net/jan/archive/2010/03/01/scriptsrc-referencing-javascript-files-with-sharepoint-2010-custom-actions.aspx


Please post your comments:


Your feedback will be submitted for moderation, and will appear after it is approved.

Name:  
Email (optional): Your email address will not be posted.
URL (optional):
Comments: HTML will be ignored, URLs will be converted to hyperlinks  
Enter the text you see in the box: