Apr 30, 2008

debuging configuration .net

The .net configuration save feature can not be used with debugging , and the configSource can only work with configurationSection, it does not work with configurationGroup.

Apr 29, 2008

Site definitions and configruations

A site definition defines unique type of Sharepoint site. There are five site definition natively installed in WSS. A site definition can inculde more than one site definition configuration. Sharepoint web site are based on particular site definition configurations.

  • STS incudles the site definition configurations for team site, blank site, and document workspace.
  • MPS includes the site definition configurations for basic meeting workspace, blank meeting workspace, decision meeting workspace, social meeting workspace, and multiple meeting workspace.
  • CENTRALADMIN provides a site definition configuration for central administration web sites
  • Wiki provides a site definition configuration for web sites that support community content using wiki technology
  • BLOG provides a site definition configuration for blogs.

Site definition files are cached in memory on the server at process startup of Microsoft Internet Information Services (IIS), which improves scalability and performance by reducing unnecessary data storage or retrieval, and by allowing uncustomized pages to be reused across sites. The information contained in these files is pulled from the cache at run time. Pages and list schemas are read from the site definition files but appear to be actual files within a site, which is why these files are referred to as "ghosted." Ghosted pages are therefore pages whose actual content does not reside in the database but on disk. A row for each page is in the database and it contains a column value that points to the source for the page in the file system. New Web Part pages are also ghosted.

When site pages are customized, excluding browser-based customizations such as modifications to Web Parts, the pages become "unghosted" and their contents are stored in the database. Uploaded .aspx files are considered unghosted automatically. The contents of unghosted pages are routed through safe mode parsing in ASP.NET, which prevents server-side code from executing, and which depends entirely on the Safe Controls list — specified in the web.config file of the Windows SharePoint Services application's subfolder in C:\Inetpub\wwwroot\wss\VirtualDirectories — to determine which controls can be rendered at run time.

Core Schema files

  • Onet.xml

    Defines the navigation areas, specifies the list definitions available on the Create page, specifies document templates and their files, defines the base types for lists, and defines configurations and modules for site. The folder is definitions.\TEMPLATE\SiteTemplates\ site_type \XML . There may be other files and folders in the xml folder. For example, default.aspx, lists folder , dwp folder

  • Schema

    Defines the views, forms, toolbar, and special fields in a list definition. Each definition has its own Schema.xml file. They are in folder \TEMPLATE\FEATURES\List_Definition_Name

  • WebTemp.xml

    Identifies the site definitions and provides information about how their configurations will appear in the template selection section of the New Sharepoint site page. The folder is "\Template\1033\xml".

  • DocIcon.xml

    Maps the file ProgIDs and file extensions of document types to specific for opening each type.


allow inline code in site page

By default, inline code is not allowed in site page. This can be changed by using the following.

Apr 28, 2008

Enumerating AppDomains

Here is section of code that can list all AppDomain of the current process

using System.Runtime.InteropServices;       // for domain enum
using mscoree;                              // for domain enum. Add the following as a COM reference - C:\WINDOWS\Microsoft.NET\Framework\vXXXXXX\mscoree.tlb
namespace MyNS

    public class ListProcessAppDomains
        public static IList GetAppDomains()
            IList _IList = new List();
            IntPtr enumHandle = IntPtr.Zero;
            CorRuntimeHostClass host = new mscoree.CorRuntimeHostClass();
                host.EnumDomains(out enumHandle);
                object domain = null;
                while (true)
                    host.NextDomain(enumHandle, out domain);
                    if (domain == null) break;
                    AppDomain appDomain = (AppDomain)domain;
                return _IList;
            catch (Exception e)
                return null;

Apr 27, 2008

ghosting vs unghosting

Page ghosting is an optimization used with site pages in which a single page template can be used to process multiple page instances across many different sites. For example, the home page for every team site in a WSS farm is based on an underlying page template named default.aspx that resides on the file system of the front-end web server. A page template is complied into an assembly DLL and loaded into memory just once per web application. However, this page template and its efficent useage of memory can still be used to server up pages for thousands of sites. This an obvious advantage toward scalability.

When a user costomizes a site page by using the SharePoint Designer and then save those changes, a customized version of the page definition is stored in the content database. While this provide flexibility form a customization standpoint, it also can have negative impact on performance and scalability. When the customized page is requested, its page definition must be retrieved from the backend database server by the SPVirtualProvider component and then fed to the ASP.NET compiler, where is parsed and loaded into memory. You can imagine that a web application with thousands of customization pages requireds more memory becaused each customized page definition must be serperately parsed and loaded into memory within the application pool that is hosting the current web application.

You should note that customized pages are not processed by using the standard ADP.NET in which a page is compiled into an assembly DLL. Instead, customzied pages are parsed by the ASP.NET page parser and then processed using the no-compiled mode feature that was introduced with ASP.NET 2.0

As a developer, your initial reaction to this might be to question why customized pages are processed in no-compile mode. Your instincts likely tell you that compiled pages run faster than no-compile pages. However, no-compile pages can be more efficient and more scalable in certain scenarios. This is especially true in a large WSS environment where the number of customized pages can reach into the thousands or tens of thousands.

No-compile pages can be loaded into memory and then unloaded in a manner that is not possible for compiled pages because the .NET Framework doesn’t really support the concept of unloading an assembly DLL from memory. The closest equivalent would be to recycle the current Windows process or the current .NET AppDomain. However, this type of recycling involves unloading all assembly DLLs from memory, not just those assembly DLLs that haven’t been used recently. Furthermore, the .NET Framework places an upper limit on the number of assembly DLLs that can be loaded into a .NET AppDomain.

No-compile pages provide higher levels of scalability because they do not require loading new assembly DLLs or managed classes into memory. Instead, the processing of no-compile pages involves loading control trees into memory. WSS can manage the memory usage for the control trees associated with customized pages more efficiently because they are not compiled into assembly DLLs. For example, once WSS has finished processing a customized page, it can unload the page’s control tree to free up memory for other purposes. Furthermore, nocompile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.

Application page vs Site Page

Application page resides in file system, site page reside in sql server.