Monday, July 9, 2012

SandBox Sol

u cannot run with elevated privilideges

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



================================================================

Site collection administrators now have the authority to upload, activate, delete, and manage sandboxed solutions using the new Solution Gallery, which is a repository of sandboxed solutions. The gallery also enables a site collection administrator to monitor a solution’s usage against a resource quota. (You will see how in detail later in the article.) The Solution Gallery is simply a standard SharePoint list that stores the .wsp file. It is located under the _catalogs folder at _catalogs/solutions

But what you can do is read and write to lists and libraries within the same site collection. The sandbox provides enough functionality to build most of the applications that are required at a site level.
The best way to reach out of the sandbox is by using the Business Connectivity Services (BCS) to create an external content type. You can then read and write to the data source from the sandboxed solution.
Another, more advanced, way to reach outside the sandbox is to create a class that runs in a full-trust process outside the sandboxed worker process to proxy calls.  
To enable the same we can follow the following steps :

     http://msdn.microsoft.com/en-us/library/ff798476

The ExecutionModels.Sandboxed.Proxy solution illustrates everything you need to know to create and deploy a full-trust proxy. At a high level, you must complete three key tasks to make a full-trust proxy available to sandboxed solutions:
  • Create a proxy operation arguments class that represents the data that you want to pass to your full-trust proxy. This class should inherit from the SPProxyOperationArgs base class. The proxy operation arguments class is essentially a serializable collection of user-defined public properties.
  • Create a proxy operations class that implements your full-trust logic. This class should inherit from the SPProxyOperations base class. The base class defines a single method named Execute that requires a single argument of type SPProxyOperationsArgs and returns a value of type Object.
  • Register your full-trust proxy with the user code service. This is best accomplished through the use of a feature receiver class. The registration process makes your proxy operation arguments class available in the sandbox environment, and it enables you to invoke your proxy logic through the SPUtility.ExecuteRegisteredProxyOperation method.


Site collection administrators now have the authority to upload, activate, delete, and manage sandboxed solutions using the new Solution Gallery, which is a repository of sandboxed solutions. The gallery also enables a site collection administrator to monitor a solution’s usage against a resource quota. (You will see how in detail later in the article.) The Solution Gallery is simply a standard SharePoint list that stores the .wsp file. It is located under the _catalogs folder at _catalogs/solutions

But what you can do is read and write to lists and libraries within the same site collection. The sandbox provides enough functionality to build most of the applications that are required at a site level.
The best way to reach out of the sandbox is by using the Business Connectivity Services (BCS) to create an external content type. You can then read and write to the data source from the sandboxed solution.
Another, more advanced, way to reach outside the sandbox is to create a class that runs in a full-trust process outside the sandboxed worker process to proxy calls.  
To enable the same we can follow the following steps :

     http://msdn.microsoft.com/en-us/library/ff798476

The ExecutionModels.Sandboxed.Proxy solution illustrates everything you need to know to create and deploy a full-trust proxy. At a high level, you must complete three key tasks to make a full-trust proxy available to sandboxed solutions:
  • Create a proxy operation arguments class that represents the data that you want to pass to your full-trust proxy. This class should inherit from the SPProxyOperationArgs base class. The proxy operation arguments class is essentially a serializable collection of user-defined public properties.
  • Create a proxy operations class that implements your full-trust logic. This class should inherit from the SPProxyOperations base class. The base class defines a single method named Execute that requires a single argument of type SPProxyOperationsArgs and returns a value of type Object.
  • Register your full-trust proxy with the user code service. This is best accomplished through the use of a feature receiver class. The registration process makes your proxy operation arguments class available in the sandbox environment, and it enables you to invoke your proxy logic through the SPUtility.ExecuteRegisteredProxyOperation method.


========================



Today i was trying hard to
upload
activate
a .wsp file that i had built using VS 2010.

After creating the file.YOu upoload the file  from the site pages
Then yopu have to come to the root pager and open site actions>site settings .
There > Solutions .
You will see the list of solutions that u have/had uploaded.
Now u can activate/deactivate the same for the entire site collection.



Why use SharePoint 2010 Sandboxed Solutions?Title: Why use SharePoint 2010 Sandboxed Solutions?
Details: Below are few thoughts on why to use Sandboxed Solutions
    Isolation        Deployed to the database ( no files within the SBS will touch file system ).
        Runs under special process, SPUCWorkerProcess.exe
        Assign Resource Points
        Doesn’t effect other Site Collections
    No waiting for farm admins to deploy your solutions
    Farm admins don’t need to worry about bad solutions any more
    Runs on partial trust
    Can be monitored
    Can be validated


Note:
The standard Visual Web Part is not supported in the sandbox environment. The reason for this is because Visual Web Parts
effectively host an ASCX user control within the Web Part control. The ASCX file is deployed to the _controltemplates virtual directory in the physical file system on each Web front-end server. The sandbox environment does not allow you to deploy physical files to the SharePoint root, so you cannot use a sandboxed solution to deploy a Visual Web Part based on the Visual Studio 2010 Visual Web Part project template.
A Visual Studio Power Tool is available that addresses this issue. A Power Tool is a plug in for Visual Studio. The tool will generate and compile code representing the user control (.ascx) as part of the assembly. This avoids the file deployment issue. You can download a Power Tool for Visual Studio 2010 that supports Visual Web Parts in the sandbox from
Visual Studio 2010 SharePoint Power Tools on MSDN.

No comments:

Post a Comment