You can target your solution as sandboxed only if all of your solution component fall within following SharePoint items:
Web Parts (code only; not visual Web Parts)
You can not target your solution as sandboxed, in case any of your solution components fall within following SharePoint items:
Visual Web Parts (they contain web controls that have to be deployed to disk)
Business data connectivity models
Call web services in an intranet or over the Internet
Access data outside the site collection where the solution has been deployed
Read and write files with your code
Run code that is not marked to allow partially trusted callers
Use objects above SPSite (e.g., SPFarm)
Use security-related functions (RunWithElevatedPreviledges)
Impersonation of Users
Custom Workflow or programmatically invoking SharePoint Designer workflow
Programmatically accessing Taxonomy data/ Metadata Management
Looking at the above allowed/restricted items, it is quite evident that Sandbox solutions would provide more security and control but lesser features. Whereas farm based solution would not restrict any thing but it would developer’s prerogative to handle the security and avoid malicious code, which would result into more number of code reviews and unit testing
To query SharePoint List or Document Library in specific Folder “ FolderServerRelativeUrl ” as part of the CAML Query Code Snippet ...
Recently, I stumbled upon a situation where I had Calendar list and I had provided custom save and cancel button. In List setting I had kep...
In order to call a web service in sandbox environment following steps should be followed. Note: Assuming you already have c...