Beruflich Dokumente
Kultur Dokumente
An example of such a restriction - being able to make changes to the file system, even during deployment. This is why a Visual WebPart which involves the deployment of an ASCX is not allowed in a sandbox solution. But it is important to understand the architecture of how sandbox solutions work before we can talk about the specific restrictions. The word "sandbox" in computers is generally used to refer to a safe area where you can play, without damaging the outside hosting environment. The sandbox in SharePoint is implemented as a separate process where your sandbox solution code will run. In fact, there are three processes.
b) Go to Central Administration\System Settings\Manage User Solutions and specify the desired load balancing behavior as indicated in the figure below.
7. SPTransformUtilities 2. Microsoft.SharePoint.Navigation 3. Microsoft.SharePoint.Utilities, except 1. SPUtility.SendEmail 2. SPUtility.GetNTFullNameandEmailFromLogin 4. Microsoft.SharePoint.Workflow 5. Microsoft.SharePoint.WebPartPages, except 1. SPWebPartManager 2. SPWebPartConnection 3. WebPartZone 4. WebPartPage 5. ToolPane 6. ToolPart So as you can see, as long as you can fit your solution within the above constraints, you can deliver very compelling functionality. It is important to note however that when you create a new Visual Studio SharePoint project, and choose to make the solution a sandbox solution, visual studio will trim it's intellisense to reflect the restricted API. However, if you choose to hand type in one of the restricted APIs above, and compile and deploy your project, it will still compile and deploy! It just won't execute. This is because, your sandbox solution code is validated against the restricted API as indicated above, but it is compiled against the full API. So here is a little trick! If you want to make sure that you aren't using any of the restricted APIs before you deploy your solution, manually reference your project against [SharePoint Root]\UserCode\assemblies\Microsoft.SharePoint.dll. If your code compiles, then you're pretty safe! Of course, NEVER deploy code with this user code Microsoft.SharePoint dll references, instead reference the Microsoft.SharePoint.dll in the [SharePoint Root]\ISAPI folder. While you are in the [SharePoint Root]\UserCode folder, you will also note a web.config there. If you open that web.config, you will see a trust level entry as shown below: <trustLevel name="WSS_Sandbox" policy File="..\config\wss_usercode.config" /> Thus as you can see, the sandboxed solutions are also restricted by an out of the box CAS policy. Thus the sandbox is non-negotiable! You shouldn't edit this file to define the boundaries of your own sandbox, you should stick with the boundaries that Microsoft defined for you! Specifically, the CAS policy for sandbox solutions grants you the following policy permissions: 1. SharePointPermission.ObjectModel
2. SecurityPermission.Execution 3. AspNetHostingPermission.Level = Minimal There are two other important points to note in this out of the box CAS Policy 1. While your code is restricted to the CAS policy permissions defined above, it allows the SharePoint framework code full trust. 2. If your custom code needs to break out of this sandbox's boundaries, you can always write a full-trust pro