Everything went pretty smooth for development and UAT environment until the final deployment to the production farm. After firing off the PS script, everything seems pretty dandy and up-running, except the styling and Ajax stopped working for unknown reasons.
Once quickly fire-off my best pal (Firebug & Chrome Development Console), the problem was revealed in a second by the Absolutely Path not working since we altered the site-collection structure in the production environment.
Then the question came to me that how we could come up a better reference Url rather than hard-coded or the absolute one. After quickly looking this up from MSDN, I came up this quick and neat solution below:
<asp:ScriptManager id="ScriptManager" runat="server" EnablePageMethods="false"
EnablePartialRendering="true" EnableScriptGlobalization="false" EnableScriptLocalization="true">
name="<% $SPUrl:~sitecollection/Style Library/ProjectPortal/ppb-styles.css %>"
As the codes shown above, the magic trick here is all about leveraging syntax in order to get the proper URL path populated regardless of the change of the URL path since the site collection level structure has been modified.
As for the sake of the best practice, we have determined to use WSP to deploy all custom MasterPages, styling recourse and Ajax script components, thereby this little tip is definitely benefiting us in the long-run.
From SharePoint 2010, Sandboxed solution has been released as one of the highlight features, by which the SharePoint developers can implement the fancy functionality added onto the SharePoint farm without impacting the entire application. Not to mention, the Sandboxed code is completed executed outside of the w3wp.exe process (SharePoint runs sandboxed solution code in a process SPUCWorkerProcess.exe), in other words, whatever the error caused by the Sandboxed solution will not be able to bring down the entire SharePoint portal solution.
Ironically, it just sounds too good to be true at some extent. At the recent project, for proof-of-concept, we were keen to use Sandboxed solution as the initial attempt for all the custom solution, however, after a week time, we have already landed our ship on the following obstacles or so-called limitations:
- First off, Sandboxed solutions do not support the following capabilities and elements:
- Visual Web Parts
- Application Pages
- Custom Action Group
- HideCustomAction element
- Content Type Binding
- Web Application-scoped features
- Farm-scoped features
- Workflows with code
- SharePoint 2010 Sandboxed Solution doesn't provide meaningful compiling and run-time error description. After deploying the sandboxed solution the farm, it will just throw the "Web Part Error: Sandboxed code execution request failed." , by which it just doesn't provide enough information or clues to the developers.
- SharePoint 2010 Sandboxed Solution is not allowed to access the following SharePoint APIs or components, even though the solution itself compiles successfully and executed without throwing an exception:
- a. HttpContext Cache Object
- b. ScriptManager
- c. ClientScriptManager
- d. HttpRequest.Files
- e. MasterPage
- f. Response.Redirect, Server.Transfer, SPUtility.Redirect
- g. And so on….
- The old-school Embedded resource will not work as well, unless include the resource file as part of the feature installed on the farm/site/web level.
In a nutshell, the Sandboxed solution baked from SharePoint 2010 release isn't as good as it seems to be. It definitely has its own places to be benefited, on the flip side, it just reveals a lot more limitations than its selling point from the surface. As a SharePoint consultant, I'm keen to see what the new SharePoint release could improve the Sandboxed solution.