Sandbox solutions seem to be too severely crippled

I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.

However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).

It seems to me that my WebParts will always want to do at least one of those t开发者_运维问答hings. (WebParts that don't communicate are not really that modular are they?)

Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?

Yes, I agree with you that Sandbox solutions are very restrictive.

But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).

This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.

That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.

I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons: a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm. b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution. c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?

I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.

Here's a useful guide from MS:

http://msdn.microsoft.com/en-us/library/ff798382.aspx

If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.

However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.

Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox. 1. no session 2. no web-part communication 3. no file upload controls 4. no redirect...

and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.

most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.

if you can stay out of sandbox