Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm.
When you debug a SharePoint project whose Sandboxed Solution property is set to “farm solution,” the system’s IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project’s site URL is recycled.
Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.
The following is an explanation of the 2 types of Authentication. This is well documented on the web!
Classic Mode: This is nothing but Windows Authentication. If any web application is created with Classic Mode Authentication then it cannot applicable to configure forms based authentication. That is basically it.
Claims Based: In SharePoint 2010 for a web application we can enable both windows AND forms authentication. In earlier implementation to do this, we have to create two web applications which has different zones and different authentication. But, with the new claims based authentication a single application can have the capability to configure both windows and forms under single URL. All this is possible because of the authentication framework is built on Microsoft Identify Foundation, and it uses “Geneva” framework to handle this authentication.
Convert from Classic Windows to Claims Based Authentication: To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.
WARNING! This cannot be UNDONE!
At the PS Prompt Type the following commands and press enter after each one.
Site pages are pages that are created, edited, and customized by end users.
They are primarily used for the content in a site.
Site pages come in two types—a standard page and a Web Parts page.
A standard page contains text, images, Web Parts, and other elements.
A Web Parts page contains Web Parts in Web Part zones. They have a predefined layout that uses Web Part zones.
Both types of site pages are edited using a Web browser or Microsoft SharePoint Designer.
Site pages are provisioned from a template page that is stored on the file system of the front-end Web server. When a site is provisioned, SharePoint Foundation creates a pointer to the instance of the page template on the file system. This allows SharePoint Foundation to avoid repeatedly creating copies of the pages, which are provisioned each time a site is created.
When a user customizes a site page, the template for the page is then stored in the content database. The page is retrieved from the content database every time it is requested by a user.
A customized page can, however, be reset to the original template page through the Web browser or a tool such as SharePoint Designer.
Customized site pages cannot contain in-line server code. The set of controls that are allowed to run on the page is governed by the safe controls list in the <Drive>:inetpubwwwrootwssVirtualDirectories<port number>web.config file.
It is a recommended best practice to avoid using server-side code on site pages when developing site definitions. If a user later edits or modifies that page, the code will no longer run.
The following are general rules for using server-side code on a site page.
If the page is uncustomized, server-side code is supported on the page.
If the page is customized, server-side code does not run, and the page does not render. This includes the code-behind for the page itself.
An administrator can add a PageParserPath setting in the web.config file that allows server-side code to run on pages stored at a specified path. This can be a single, specific page or an entire directory of pages.
Adding PageParserPath settings gives anyone who can upload pages to the specified folders the ability to write arbitrary, full-trust code to the server. Administrators should use extreme caution when providing these settings and understand the security implications to this action.
The following sample shows a PageParserPath setting that uses a wildcard. Adding this PageParserPath will allow anyone with permissions to the master page gallery to upload server-side code. Use extreme caution when adding this type of PageParserPath setting.
Application pages are used to support application implementations in SharePoint Foundation.
Application pages are stored on the file system of the front-end Web server in the %ProgramFiles%Common FilesMicrosoft Sharedweb server extensions14TEMPLATELAYOUTS directory and exist for every site in a Web application.
This folder is mapped to an Internet Information Services (IIS) virtual directory called _layouts. Every site and subsite will have access to the application pages by using the _layouts virtual directory.
For example, http://myserver/_layouts/settings.aspx and http://myserver/subsite/_layouts/settings.aspx access the same application page on the front-end Web server unlike site pages, which are an instance for the specified site.
* Application pages are not subject to the same restrictions as site pages. They allow in-line code without restriction.
* They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer.
* Modifying the default application pages is not supported in SharePoint Foundation. Custom application pages can be added to a subdirectory inside the _layouts folder.