Add new document to Document Library in SharePoint using C#

          We are exploring SharePoint 2007 from last few days. Here is the code for adding new document to document library using C#.  I have created a page with a file upload control and a button. When user clicks on button the selected document will be uploaded to specific document library. You need to add reference to Microsoft.SharePoint DLL to make this code running.

if (FileUpload1.PostedFile != null)
{
            if(FileUpload1.PostedFile.ContentLength > 0)
            {
                   System.IO.Stream strm =
                         FileUpload1.PostedFile.InputStream;

                   byte[] byt = new byte[
                           Convert.ToInt32 (
                  FileUpload1.PostedFile.ContentLength)];

                   strm.Read(byt, 0, Convert.ToInt32
                        (FileUpload1.PostedFile.ContentLength));

                   strm.Close();

                // Open site where document library is created.
                using (SPSite objSite = new SPSite
                                                ("http://server:port/"))
                {
                    using (SPWeb objWeb = objSite.OpenWeb())
                    {
                        SPFolder mylibrary = objWeb.Folders["Name of
                                                     Document Library"];

                        // Set AllowUnsafeUpdates = true to avoid
                        // security error
                      
                        objWeb.AllowUnsafeUpdates = true;

                        mylibrary.Files.Add(System.IO.Path.GetFileName
                               (FileUpload1.PostedFile.FileName), byt);
                    }
                }
            }
        }

     Above code first reads the uploaded file in Stream and than uploads it on document library.

Happy Programming !!!

Add aspx page to SharePoint 2007

            This post will show how to create aspx (web page) page to SharePoint 2007. You can find  a really good article to add custom page in SharePoint 2007 site. I have shown one approach describe in above article.

            Create a new Web Application Project from Visual Studio 2005. You need to download web application project extension for this. Open Visual Studio 2005 and select Web Application Project as shown below,

Fig - (1) Create new Web Application

            Name the project "FirstWebProject". Delete Default.aspx page and add new Web Page and name it to "FirstCustomePage.aspx".  You can design this page as you want. Once you are done with designing run the application once to make sure that there is no error.

            Now go to the file path where you have created the Web Application. Here in my case as you can see in figure - (1) file path is "c:\chirag\VortalProject". You have to copy the DLL file from web application's BIN folder to share point site's BIN folder. To Find BIN folder for your share point site, go to IIS and select your share point site. Right click on the site name and click on Open.

Fig - (2) Locate BIN Directory for SharePoint Site.

          This will open physical location where you site resides. Copy web application's DLL file (In my case "FirstWebProject.dll") in BIN directory of SharePoint site.

          Now create a new folder at same level where your SharePoint site's BIN directory resides. Name is "CustomePage". Add the "FirstCustomePage.aspx" page to "CustomPage" folder.

         Open Web.Config file of Share Point site and copy safe control tag shown below to Web.Config file.

<SafeControl Assembly="FirstWebProject" Namespace="FirstWebProject" TypeName="*" />

Fig - (3) Safe Control Tag.

         If you have chosen different namespace and assembly names than you have to use your name instead of this. You have completed 90% of the task.

          The last thing is, you have to add <trustLevel> tag in share point sites's web.Config file. You need to  set trust level to "WSS_Medium"

<trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_mediumtrust.config" />

Fig - (4) Setting Trust Level.

          Here you have completed all the required configurations !!!! Now open your share point site in browser and check for newly added page. In our case the link will be http://ServerName:PortNumber/CustomePage/FirstCustomePage.aspx

         If you have done all the changes as mentioned above you can see your page running fine in browser.

Happy Programming !!! 

Page Ghosting & UnGhosting And effect of PageGhosting on Performance in SharePoint 2007

           The WSS team created a virtual path provider named SPVirtualPathProvider that is integrated into every Web application. The SPVirtualPathProvider class is integrated into the ASP.NET request handling infrastructure by the SPRequestModule. More specifically, the SPRequestModule component contains code to register the SPVirtualPathProvider class with the ASP.NET Framework as it does its work to initialize a Web application.

Fig - (1) Execution flow for SharePoint pages. 

Page Ghosting and UNGhosting

             When a page instance is initially provisioned from a page template, WSS doesn’t need to store a copy of it in the content database because WSS can load the page template from the file system of the Web server and use it to process any request for an uncustomized page instance. Therefore, you can say that page ghosting describes the act of processing a request for an uncustomized page instance by using a page template loaded into memory from the file system of the front-end Web server.

             Page ghosting is valuable because it eliminates the need to transfer the contents of a page definition file from the SQL Server computer with the content database to the front-end Web server computer. Page ghosting also makes it possible to process the home pages for thousands of different

sites by using a single page template that is compiled into an assembly DLL and loaded into memory in the IIS worker process just once per Web application. Both of these optimizations are key factors in the scalability of WSS in high-traffic environments running thousands or tens of thousands of sites.

            When you modify a page and save a customized version of it in the content database using SharePoint Designer, you eliminate the possibility of page ghosting. Instead, the provided SPVirtualPathProvider must retrieve the customized version of the page from the content database, as shown in Figure 2-6. For this reason, customized pages are sometimes referred to as unghosted pages.

            Now that you understand how WSS processes requests for both ghosted and unghosted pages, you should observe the important role that is played by the SPVirtualPathProvider. It is the SPVirtualPathProvider that determines whether the page being requested has been customized. The SPVirtualPathProvider makes the decision whether to process a page as a ghosted or an unghosted page.

             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, no-compile pages eliminate the need to go through the compilation process, which actually provides faster response times for pages upon first access.

NOTE: Reference taken form Inside Microsoft Windows SharePoint Service 3.0