The sandboxed solution is one of the more promising new features in SharePoint 2010. With sandboxed solutions, developers can write solutions that can be easily deployed and executed in a shared hosting environment. This opens up a myriad of opportunities for SharePoint developers to bring solutions to the marketplace, and for lower privileged administrators to acquire and install third-party components. Before you jump right in and start developing sandboxed solutions, there are some limitations that you should consider.
Before you start ranting and raving about the information I am about to share, it is helpful to take a step back and consider why you would want to develop for the sandbox in the first place. If you want to relate a sandboxed solution to something outside of SharePoint, consider a WordPress module, iPhone application, or Facebook application. None of these platforms will allow solution providers to access sensitive information on or change the properties of the platform itself. They provide a specific function, usually self-contained and not reliant on any other application on the platform (unless their function is to enhance or extend an existing application). Sandboxed solutions should be thought of in the same regard. So what are the limitations?
Directly Accessing a Database
Sandboxed solutions cannot directly read from or write to a database on the server. This makes sense when you think about it. Most SharePoint shared hosting environments do not provide access to a database anyway. After all, much of the content you will want to work with in a sandboxed solution will be in SharePoint lists, and you have access to those. Sometimes, however, you may want to view and edit data from one of your core business systems. To access that data, you can use a “Hybrid Approach”. One such approach involves creating an external content type for the line of business data, then using the SPList API in the sandbox to work with that data. This is less of a workaround and more of a structured approach to working with external data in a sandboxed solution. What I am really saying is that ADO.NET cannot be used to directly access data from a sandboxed solution. While this may be a hurdle for traditional ASP.NET developers, it is not insurmountable.
Writing to the Disk
From a sandboxed solution, you cannot directly write to the disk of the application server. Again, you can write to SharePoint lists in a sandboxed solution, so this is hardly a show stopper. The primary reason one would want to write to the disk from a SharePoint solution, in my opinion, is to write to log files. You can use a full-trust proxy with the SharePoint Logger to write to the Windows Event Log and SharePoint Unified Logging Service (ULS) logs.
Accessing the Objects in another Site Collection
Since site collections are a common container for SharePoint deployments in a shared hosting environment, limiting access of a sandboxed solution to objects in the current site collection seems like a good thing. It is often beneficial to rollup content from multiple site collections in an on-premise installation. If you insist on using a sandboxed solution, workarounds will surface using hybrid approaches and so forth. However, you should consider using a farm solution for accessing other site collections for on-premise or dedicated hosting environments.
Writing Fully Coded Workflows
As you may know, there are two ways to create workflows for SharePoint 2010: using SharePoint Designer 2010 to create declarative workflows and using Visual Studio 2010 to develop custom workflows. The limitation is related to the latter. Consider that most of the reasons you would want to write a custom workflow are not possible in the sandbox anyways. For example, you do not have access in a Visual Studio 2010 sandboxed solution to the farm-level objects that are used to send emails, and sending emails is a common activity in workflows. SharePoint Designer 2010, on the other hand, was designed to create solutions using pre-defined tasks (such as sending emails) within the confines of the current site. As with the other limitations, there will be workarounds. In order to keep it simple, however, you should consider using declarative workflows in a sandbox and deploying coded workflows as a farm solution when environment allows for it.
Developing Visual Web Parts
I have included this as a limitation only to set the record straight. Visual Studio 2010, out of the box, does not allow you to use the visual editor to create Web Parts for a sandboxed solution. This caused quite the uproar initially since the visual Web Part was one of the most highly anticipated Visual Studio 2010 enhancements for SharePoint developers. Microsoft responded quickly with a Visual Studio 2010 Power Tool for SharePoint 2010 developers. In addition to allowing for visual editing of sandboxed Web Parts, this Power Tool provides some helpful compiler tips.
Before you start ranting and raving about the information I am about to share, it is helpful to take a step back and consider why you would want to develop for the sandbox in the first place. If you want to relate a sandboxed solution to something outside of SharePoint, consider a WordPress module, iPhone application, or Facebook application. None of these platforms will allow solution providers to access sensitive information on or change the properties of the platform itself. They provide a specific function, usually self-contained and not reliant on any other application on the platform (unless their function is to enhance or extend an existing application). Sandboxed solutions should be thought of in the same regard. So what are the limitations?
Directly Accessing a Database
Sandboxed solutions cannot directly read from or write to a database on the server. This makes sense when you think about it. Most SharePoint shared hosting environments do not provide access to a database anyway. After all, much of the content you will want to work with in a sandboxed solution will be in SharePoint lists, and you have access to those. Sometimes, however, you may want to view and edit data from one of your core business systems. To access that data, you can use a “Hybrid Approach”. One such approach involves creating an external content type for the line of business data, then using the SPList API in the sandbox to work with that data. This is less of a workaround and more of a structured approach to working with external data in a sandboxed solution. What I am really saying is that ADO.NET cannot be used to directly access data from a sandboxed solution. While this may be a hurdle for traditional ASP.NET developers, it is not insurmountable.
Writing to the Disk
From a sandboxed solution, you cannot directly write to the disk of the application server. Again, you can write to SharePoint lists in a sandboxed solution, so this is hardly a show stopper. The primary reason one would want to write to the disk from a SharePoint solution, in my opinion, is to write to log files. You can use a full-trust proxy with the SharePoint Logger to write to the Windows Event Log and SharePoint Unified Logging Service (ULS) logs.
Accessing the Objects in another Site Collection
Since site collections are a common container for SharePoint deployments in a shared hosting environment, limiting access of a sandboxed solution to objects in the current site collection seems like a good thing. It is often beneficial to rollup content from multiple site collections in an on-premise installation. If you insist on using a sandboxed solution, workarounds will surface using hybrid approaches and so forth. However, you should consider using a farm solution for accessing other site collections for on-premise or dedicated hosting environments.
Writing Fully Coded Workflows
As you may know, there are two ways to create workflows for SharePoint 2010: using SharePoint Designer 2010 to create declarative workflows and using Visual Studio 2010 to develop custom workflows. The limitation is related to the latter. Consider that most of the reasons you would want to write a custom workflow are not possible in the sandbox anyways. For example, you do not have access in a Visual Studio 2010 sandboxed solution to the farm-level objects that are used to send emails, and sending emails is a common activity in workflows. SharePoint Designer 2010, on the other hand, was designed to create solutions using pre-defined tasks (such as sending emails) within the confines of the current site. As with the other limitations, there will be workarounds. In order to keep it simple, however, you should consider using declarative workflows in a sandbox and deploying coded workflows as a farm solution when environment allows for it.
Developing Visual Web Parts
I have included this as a limitation only to set the record straight. Visual Studio 2010, out of the box, does not allow you to use the visual editor to create Web Parts for a sandboxed solution. This caused quite the uproar initially since the visual Web Part was one of the most highly anticipated Visual Studio 2010 enhancements for SharePoint developers. Microsoft responded quickly with a Visual Studio 2010 Power Tool for SharePoint 2010 developers. In addition to allowing for visual editing of sandboxed Web Parts, this Power Tool provides some helpful compiler tips.
No comments:
Post a Comment