Ad
More Related Content
What's hot (20)
Similar to Diff sand box and farm (20)
Ad
Recently uploaded (20)
Ad
Diff sand box and farm
- 1. Farm Solutions: - Farm solutions are hosted in the IIS worker process (W3WP.exe). - If you run any code in farm solution the whole farm will got affected. - If you deploy any feature or retract any feature the whole application pool got recycled. - Since they are scoped as farm level, they have full trust access to all the resources. - When the Sandboxed Solution property is set to False, selecting BuildDeploy will deploy the solution to the Farm Solution Gallery. Sandboxed Solution: - Sandboxed solutions are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe). - The process runs under a CAS policy that restricts programmatic access to any resource outside the sandbox. So it never restart the IIS application pool. - If you run any code it will affect only the site collection of the solution. - Helpful if you have shared hosting. - When the Sandboxed Solution property is set to True, selecting BuildDeploy Solution deploys the solution to the site collection Solution Gallery. One major difference in the deployment is Farm solutions are installed and deployed. Sandboxed solutions are uploaded and activated. We can’t create VISUAL web parts in Sandbox solutions. We can’t use code to connect to the external web services or to database Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls Here the processes which required for Sandbox solutions. 1. SPUCWorkerprocess.exe - Sandbox Worker process service which is a Seperate Service Application which actually executes Sandbox code. It should be started in every farm to use Sandbox solutions. 2. SPUCWorkerProcessProxy.exe - Sandbox Worker process proxy which is working as a proxy for Worker process and takes care of Sandbox code
- 2. execution. It can also serve to other farms if configured. Basically it helps site administrator for load balancing. 3. SPUCHostService.exe - Sandbox User Code Service takes care of user code in Sandbox amd it can be started in the farms where to use Sandbox solutions. Sandbox Limitations: As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in SharePoint environment. Few key limitations which developers should know are listed below. 1. No Security Elevation - RunWithElevatedPrivileges which runs the specified block of code in application pool account(typically System Account) context is not allowed in Sandbox code. SPSecurity class also not allowed to use in Sandbox. 2. No Email Support - SPUtility.SendMail method has been blocked explicitly in Sandbox, However .Net mail classes can be used to send mails. Additionaly sandbox won't allow to read Farm SMTP address. So developers has to specify the SMTP address in code itself(may be some other workaround). 3. No Support to WebPartPages Namespace - Sandbox won't allow to use Microsoft.SharePoint.WebPartPages namespace. 4. No Support to external Webservice - Internet web service calls are not allowed to ensure security in Sandbox solutions. Allow Partially Trusted code also can't be accessed within Sandbox. 5. No GAC Deployment - Sandbox solutions are not stored in File System(Physical path) and assemblies can't be deployed to Global Assembly Cache(GAC). But it's available on C:ProgramDataMicrosoftSharePointUCCache at runtime. Note the ProgramData is a hidden folder. 6. No Visual Webparts - Visual Studio 2010 by default won't allow to create Visual Webparts to deploy as sandbox solution. But with Visual Studio PowerTools extensions(downloadable from Microsoft MSDN website) Visual Webparts can be developed and deployed as sandbox Solutions Points to be noted: •One major difference is we can't create Aplication pages in Sandbox solutions.Beacuse Application pages are stored in the 14TEMPLATES_LAYOUTS and when we deploy as sandbox we dont have permissions to the physical folder. •Also we cant create VISUAL web parts in Sandbox soultions. •We cant use code to connect to the external web services or to database in the sandbox soltion •Farm solutions are installed and deployed. Sandboxed solutions are uploaded and activated. • runwithelevatedprivileges doesn't work in Sandboxed solutions.
- 3. • Site collection adminstrator can deploy a Sandboxed solutions, where as Farm administrator can only deploy Farm based Solutions. Users can deploy the below four things as sandboxed soultions : 1. WebParts. 2. Event Receivers. 3. List Definations. 4. Workflows. Comparison of CAML and LINQ in SharePoint 2010 ->Linqisa ObjectorientedQuerylanguage ->LINQis converted toCAML so CAML is betterinperformance butwritingthe queryinLINQiseasier than CAML CAML ->query is text based so, if we are joining two lists across a lookup field there may be various problems associated with that. CAML->There is no mechanism to know until run time if the query is written correctly or not. If the query is not correct, then it will simply fail at run time. Means it won't support at design time CAML->The query is somewhat difficult to understand. We cannot determine easily what the query is doing and what lists are being joined. Linq->The results are returned from queries are strongly typed objects, so the items and fields can provide compile-time checking. What is the difference between Classic mode authenticationand Claims-based authentication? classic authentication supports NT authentication types like Kerberos, NTLM, Basic, Digest, and anonymous. Claims based authentication uses claims identities against a trusted identity provider in SharePoint2013 by default web app is created as Claims based authentication mode (then you can choose windows/forms based). Claim based authentication mode supports the foll:-
- 4. 1. Windows authentication 2. Forms based authentication. Visual web parts VS Standard web parts 1. A standard web part is an item-level template in Visual Studio. That means that you can only add it as an item to your project (an empty SharePoint project for example). A visual web part can be created as both item-level and project-level. 2. In the case of the visual web part, you can use a designer experience to drag and drop items on your canvas. In the case of the standard web part, you will have to manually type everything (using IntelliSense) . 3. A standard web part can be deployed as a Farm or Sandboxed solution. A visual web part will have to be deployed as a Farm solution. http://www.randomizzzer.com/2011/06/explained-visual-web-parts-vs-standard-web-parts/ http://crmvoyager.net/2010/11/24/sharepoint-2010-web-parts-vs-visual-web-parts/ ghosting and unghosting in sharepoint Ghosting: no customization (Data will store in file system) unghosting: customization of site definition (Data will store in content DB) Site Content Types When you create a content type and add it to a site's content type collection, the new content type becomes available to any child site and also to the site where it was created. For example, if you create a site content type at the root site of a site collection, that site content type becomes available on any site in the site hierarchy. If you add a new content type to a site that is lower down in the hierarchy, it is available in the site where you add it and in any sites below that site in the hierarchy. We can create site content type inside a Sitecollection ->Site Settings->Designer Galleries- >SiteContent type List Content Type We can create a list content type inside a list->list setting
- 5. ) What are some useful, OOB features of SharePoint that aid with governance of an environment? Any of the below are acceptable answers. There are some others but these are the major ones that I generally look for from a candidate: Site templates – consistent branding, site structure, and layout can be enforce a set of customizations that are applied to a site definition. Quotas – limits to the amount of storage a site collection can use. Locks - prevent users from either adding content to a site collection or using the site collection. Web application permissions and policies – comprehensive security settings that apply to all users and groups for all site collections within a Web application. Self-service site creation - enables users to create their own site collections, thus must be incorporated into a governance scheme. 10:There are four predefined routines that take place in a WebPart Life Cycle, 1. OnInit 2. CreateChildControls 3. OnPrerender 4. Render