Nick Grattan's Blog

About Microsoft SharePoint, .NET, Natural Language Processing and Machine Learning

Archive for the ‘SharePoint Object Model’ Category

Document Libraries: SPList and SPFolder.Delete Differences

with 2 comments

Removing items from a document library can be done in two different ways. Firstly, using SPList.Delete:

int iCount = spList.Items.Count;

for (int i = 0; i < iCount; i++)

{

    spList.Items[0].Delete();

}

This code will delete all the items/documents in all folders, but will leave the folders undeleted. Alternatively, you may write:

int iCount = spFolder.Files.Count;

for (int i = 0; i < iCount; i++)

{

    spFolder.Files[0].Delete();

}

This will delete the items/documents only in the folder represented by ‘spFolder’, and items/documents in other sub-folders will remain. The references to spList and spFolder can be obtained like this:

spList = currentWeb.Lists[“MyDocumentLibrary”];

spFolder = currentWeb.Folders[“MyDocumentLibrary”];

In this case, spFolder refers to the root folder in the document library.

 

 

 

 

 

 

 

 

Advertisements

Written by Nick Grattan

October 9, 2007 at 11:43 am

SPFolder / SPList: Deleting versus Recycling

with 2 comments

The following code shows how to remove all documents from a folder:

int iCount = spFolder.Files.Count;

for (int i = 0; i < iCount; i++)

{

    spFolder.Files[0].Delete();

}

Deleting documents with this code will delete permanently without using the recycle bin. To move the document to the recycle bin use the following code:

spFolder.Files[0].Recycle();

The SPItem class has a Recycle method as well as a Delete method and can be used in a similar way.

Written by Nick Grattan

October 9, 2007 at 11:13 am

Introducing the SharePoint object model

with 24 comments

As an alternative to programming against the SharePoint web services you can use the SharePoint object model. The object model can be used when the application will run on the server where SharePoint is installed (such as a console or WinForm application) or in assemblies that are run within a site (such as a Web Part).  

This sample shows how to display the sites and sub sites within a site collection as a hierarchy in a tree view control within a WinForm application.

Treeview

First, you will need to create a reference to “SharePoint.dll” assembly in your Visual Studio 2005 project. This is located at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.SharePoint.dll

A recursive function nicely solves the problem of loading the site hierachy into a tree view control. The method below is passed the tree node into which the site list will be loaded, and a SPWeb object representing the site whose sub-sites will be loaded:

       private void FillSubWeb(TreeNode tn, SPWeb webSite)

        {

            foreach (SPWeb theWeb in webSite.Webs)

            {

                TreeNode subTN = new TreeNode(theWeb.Name);

                tn.Nodes.Add(subTN);

                FillSubWeb(subTN, theWeb);

            }

        }

This method iterates over the “Webs” collection which returns each sub-site. A new TreeNode object is created with the site name. The node is added to the tree view  control. Lastly, the FillSubWeb method is called recursively, passing the TreeNode and theWeb object to load the sub-sites for the current site.

The following code kicks off the loading of the sites:

           

      SPSite site = new SPSite

           (“http://moss2007:8100/sites/intranet&rdquo;);

      SPWeb rootWeb = site.AllWebs[0];

 

      TreeNode tn = new TreeNode

            (“http://moss2007:8100/sites/intranet&rdquo;);

      tvSites.Nodes.Add(tn);

      FillSubWeb(tn, rootWeb);

The code gets a reference to the site collection from the URL, and then obtains a reference to the top-level web (site) for the site collection. A tree node is created and added to the tree view control to represent the site collection, and then the FillSubWeb method is called to start the recursive process.

 

Written by Nick Grattan

August 10, 2007 at 4:01 pm

Extracting Public Key from Signed Assembly

with 4 comments

Once an assembly has been signed you can extract the public key token using the ‘sn’ .NET utility. This is necessary if you need to create a reference to an assembly, for example in the form:

<Field  Name=”FieldTypeClass”> RatingField.RatingField,RatingField, Version=1.0.0.0,Culture=neutral, PublicKeyToken=ef9f3072afebf3b0 </Field>

To do this:

  1. Run a Visual Studio 2005 command prompt (Visual Studio Tool + Visual Studio 2005 Command Prompt from the “Start” menu).
  2. Enter the following command:

sn -Tp ratingfield.dll

Where “ratingfield.dll” is the name of the signed assembly.

Written by Nick Grattan

August 6, 2007 at 2:14 pm

Where have my versions gone?

leave a comment »

Once enabled for a library or list, major and minor versions of documents and items can be kept; the number of which can be specified in the library or list settings:

Versions

The version history for items or documents can be viewed, and old versions can be opened and inspected. But where are these old versions stored?

Version histories are maintained for files and for property (column) values. In the case of a document library both a file and a property history is maintained, but for a list item only a property history is kept. The SharePoint class libraries or web services can be used to programmatically access this information, and also determine the URL where a pervious version of a document is located.

So, on a SharePoint server create a new Visual Studio project and add a reference to the “Microsoft.SharePoint.dll” library. Then add a using statement to “Microsoft.SharePoint.” Assuming you have already a reference to a SPList object representing the list or library you can obain a reference to the collection of previous file versions:

            SPFileVersionCollection theFileVersions = lstItem.File.Versions;

The collection can be iterated, and in this case, the version label and URL are added to a WinForm data grid view control:

            foreach (SPFileVersion liVer in theFileVersions)

            {

               int rowID = dgvVersions.Rows.Add();

               dgvVersions.Rows[rowID].Cells[0].Value = liVer.VersionLabel;

               dgvVersions.Rows[rowID].Cells[1].Value = liVer.Url;

            }

The output will look like the following:

Versions2

You can see from this that the previous versions are stored in a virtual folder called “_vti_history” under the site in which the library is located. The virtual folder “512” represents the version number (taking into account other versioned documents in the site). This URL together with the URL for the site can be used to directly open previous versions.

The SPFileVersion object can also be used to access the contents of the file. In this code, the bytes associated with the version are obtained and then saved to a file:

            byte[] outBytes = liVer.OpenBinary();

            using (BinaryWriter binWriter =

               new BinaryWriter(File.Open(@”C:\Temp\MyFile.xlsx”,

                    FileMode.Create)))

            {

               binWriter.Write(outBytes);

            }

This works well with documents, but the situation is much more complex with pages, content and web parts. Navigating to the URL for pages will result in an HTTP 404 – “file not found”.

Written by Nick Grattan

July 31, 2007 at 3:46 pm

Finding the correct w3wp.exe when debugging

leave a comment »

When using the Visual Studio Debug +Processes menu command to attach to a web site to debug you may be presented with several w3wp.exe processes under II6 with Windows Server 2003. There is one for each application pool running under IIS. Here’s how to find out which one is running your application:

  1. Run a command prompt and navigate to the Windows system32 folder
  2. Issue the following command:

cscript iisapp.vbs

The output from this script will be something like:

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

 

W3WP.exe PID: 4044   AppPoolId: MSSharePointPortalAppPool

The process id is 4044 for, in this case, SharePoint Portal Server.

Written by Nick Grattan

July 20, 2007 at 4:53 pm