SharePoint and ProjectWise in a Sandboxed Environment

SharePoint allows for secure development environment for developers to use for custom web part code deployments and testing.  This particular SharePoint environment is referred to as a “sandbox” environment.

A SharePoint sandbox environment has several security features to insulate a SharePoint Production ready environment from contamination and security breaches.  Since the sandboxed environment runs in such a secure environment, ProjectWise SharePoint Web Parts will not run properly when deployed to this type of environment.  Listed below is concise information on why it is this way.  The highlighted items directly affect ProjectWise SharePoint Web Parts.

All code that runs in this sandbox worker process is subject to execution and access constraints. There are two systems of constraints: one applies only to calls that code in sandboxed solutions makes to the main SharePoint Foundation assembly, Microsoft.SharePoint.dll. The other applies to all other calls, including calls to all other SharePoint assemblies and to .NET Framework assemblies. In this topic, the first system is called Server-side Object Model Constraints and the second system is called General Constraints. (There are also some miscellaneous constraints resulting from the split page rendering system used in sandboxed solutions. For more information, see the section Split Page Rendering System later in this topic.)

Excerpt from http://msdn.microsoft.com/en-us/library/ee539417.aspx

The General Constraints are imposed by two mechanisms:

1. 1.       A highly restrictive code access security (CAS) policy significantly limits what code in the sandboxed worker process can do.  Among the restrictions imposed by the CAS policy are the following:

1. Code in the sandbox can call only the .NET Framework 3.5 assemblies that have the AllowPartiallyTrustedCallersAttribute attribute.
2. Code in the sandbox cannot call unmanaged code.
3. Code in the sandbox cannot call the Microsoft .NET Framework 3.5 reflection APIs.

• Secondly, the sandboxed worker process has a low-privileged security token.

1. The token denies the process the right to read or write to the file system.
2. The token denies the process the right to call to the network. So, only resources that are available on the server that is running the sandboxed worker process may be accessed. An external database, for example, cannot be accessed.
3. The token denies the process the right to write to the registry.
4. The token denies the right to call to any assembly that is not in the global assembly cache, even if it has theAllowPartiallyTrustedCallersAttribute attribute and would otherwise be eligible to be called from the sandboxed worker process.

JP