Sander's Blog

A query against MOSS search engine returns a specified number of results and a indication of the total number of results. When working with the API this is the TotalRows property of the ResultsTable, working with the WebService this is the TotalAvailable element of the ResponsePacket.

If you, like me, want to base your paging on the TotalRows or TotalAvailable properties and you expect it to return the exact number of results you're in for some strange behaviour…

I do not have a nice solution yet, although the API also exposes the IsTotalRowsExact property. This will tell you when you're on the save side. The webservice ResponsePacket has not got an equalivant property.

The MSDN documentation of the API does not mention this number not being exact: http://msdn2.microsoft.com/en-us/library/microsoft.office.server.search.query.resulttable_members.aspx

The webservice documentation actually does mention it: http://msdn2.microsoft.com/en-us/library/aa193748(office.11).aspx#RangeType_TotalAvailable

"The total number available. This number may not be 100% accurate and all these results may not be accessible."

The number will become more accurate once you move to the end of the resultset.

Be warned…

Not quite that complicated, but I'm it sure can save you (and myself next time) some time.

To show the attachment paperclip in your CQWP, just add this section to the xsl:template in the ItemStyle.xsl:

<xsl:choose>
    <xsl:when test="@Attachments='1' or msxsl:string-compare(string(@Attachments),'Yes','','i')=0 or msxsl:string-compare(string(@Attachments),'N0','','i')=0">
        <img src="_layouts/images/attach.gif" border="0" alt="Attachment"></img>
    </xsl:when>
    <xsl:otherwise>
        <!-- message no attachments attached -->
       </xsl:otherwise>
</xsl:choose>

Secondly, export the webpart and add the Attachment field to the commonviewfields:

<property name="CommonViewFields" type="string">Attachments,Attachments;</property> 

This morning I did the 70-630 exam: 'Microsoft Office SharePoint Server 2007, Configuring'.

Although the specific training for this exam was cancelled last week I've passed! A lot of the questions are in fact pretty logical once you've got some Sharepoint experience. Everything's multiple choice, so determining the options that would definitely be wrong will leave you with a 50-50 change. You'll get 51 questions, ranging from Administrating MOSS 2007, to Excel Services and Search (this is not the complete list!). Just to know; there's no in-depth WSS knowledge needed.

As preparation I've read Patrick Tisseghems book: Inside Microsoftr Office SharePointr Server 2007.

Beside that I've worked through the Transcender and Pass4sure training exams. This combination is more than enough to pass.

Next exam will be Configuring WSS, after that the 2 development certifications are left.

I've had a hard time figuring out how to programatically add or edit Querystring parameters to a SPNavigationNode. The SPNavigationNode is the internal type used to build the current (left) and global (top) WSS navigation.

It seems pretty straight forward to pass the full url to the new SPNavigationNode constructor, but the querystring part gets removed by the SharePoint API.

It turns out the Querystring part is saved in a separated propertybag.

This examples retrieves an existing link and adds a Querysstring:

SPNavigationNodeCollection nodes = PublishingWeb.GetPublishingWeb(spweb).CurrentNavigationNodes;
node = nodes[4];

// Remove the UrlQueryString property because updates are not persisted 
if (node.Properties.ContainsKey("UrlQueryString"))
    node.Properties.Remove("UrlQueryString");

node.Properties.Add("UrlQueryString", "param1=foo&param2=foo");
node.Update();

Note that you should not add the "?" at the beginning of the Querystring.

Just run in some strange behaviour of the Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart, better known as the Content Query Webpart.

I want to update a large number of these webparts, so I've made the following console app doing the work for me:

    foreach (SPFile file in [spweb].Files)
    {
        using (SPLimitedWebPartManager wpMan = file.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared))
        {

            SPLimitedWebPartCollection wpColl = wpMan.WebParts;
            int numberOfWebparts = wpColl.Count;

            for (int i = 0; i < numberOfWebparts; i++)
            {
                System.Web.UI.WebControls.WebParts.WebPart wp = (System.Web.UI.WebControls.WebParts.WebPart)wpColl;

                if (wp is Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart)
                {
                    ((ContentByQueryWebPart)wp).ListGuid = [spweb].Lists[((ContentByQueryWebPart)wp).ListName].ID.ToString();
                    ((ContentByQueryWebPart)wp).WebUrl = [spweb].ServerRelativeUrl;
                    wpMan.SaveChanges(wp);
                }

                wp.Dispose();
            }

            wpMan.Web.Dispose(); // dispose manual because of a memoryleak in SPWebpartManager (http://blog.ofonesandzeros.com/2007/06/05/splimitedwebpartmanager-memory-leak)
        }
    }

This code loops through all webparts on all pages, checks to see if the webpart is a ContentByQueryWebpart and updates some properties. This works, as long as you don't change the HeaderXslLink, ItemXslLink or MainXslLink in properties the .webpart file!

As soon as you change one of those the webpartmanager will retrun a Microsoft.SharePoint.WebPartPages.ErrorWebPart. Why? Because of the following code is called by the specific properties of the ContentByQueryWebpart (actually its parent, the CmsDataFormWebpart):

internal static string MakeServerRelativeUrl(string url)
{
    return concatenateUrls(SPContext.GetContext(HttpContext.Current).Site.ServerRelativeUrl, url);
}

The webpart will always call the SPContext, but from a console application there is no web-context. Therefore when initiating the ContentByQueryWebpart, it will always thow an exception like:

"An error occured while setting the value of this property: Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart:MainXslLink – Exception has been thrown by the target of an invocation."

This can be seen as a design error, since all webparts should be able to at least expose themselves through a WebpartManager. Once the real rendering is done calls to the SPContext can be made.

Once you've (by accident of course) changed the name of the title column, there seems to be no way back.

You cannot rename the column back to Title because SharePoint tells you this is a reserved name for a column. There are some solutions on the web which require coding or database access. I found that by using the SharePoint Manager 2007 tool you can easily rename the column. No coding or SQL skills required.

Just browse to your site collection, open the Site Columns, look for your renamed column and change the name property back to Title.

Please note that you need to enable the 'full object model' mode:

This might be a very unusual case: we have one single teamsite which acts like a model for +20.000 other teamsites.

Changes made to this teamsite are copied to the others by using the Import-Export functionality of the WSS API. Because we do not want the actual content to be copied we only copy certain files; to simplify, lets say we only copy the default.aspx page.

The list and library structure is maintained through content types, every site has the same list and library structure. In the future new lists can be deployed with Content Deployment (import-export) or by script.

After we run the import (so the default.aspx pages in all sites are updated) everything looks all right; except for the list-view webparts. Although they are nicely attached to the local lists of their new environment, the 'changes' made the the views and toolbars are lost.

On one hand I can imagine this is a unsupported scenario; you cannot guarantee the list even exists in the target site.
On the other hand this issue is very similar to the "Changes that you make to the 'List View' Web Part are not retained after you save the site as a template in Windows SharePoint Services 3.0" issue: http://support.microsoft.com/kb/926284

I can't tell yet if this is really a bug. But I can tell you our workaround: use Content Query Webparts. This also has a big advantage of centrally managing the layout, which in this situation is a big plus.

Just some free advertisement of the very cool and totaly free Enhanced Content Query Webpart.

It does exactly everything the standard CQWP does, but it adds some cool features like:
- A toolbar for lists
- A content menu for documents
- Table layout
- Direct editing of the most-used webpart properties directly in the toolpane
- A code-layer which you can extent to your own needs.

Not a nice title, not a nice error as well…

I encountered this error while trying export/import a file through the object model.

Searching the net I found some posts suggesting this could be caused by the versioning in the Style Library. As soon as you've checked-in multiple major versions of a file the error 'could' occur. But that had to do with Incremental deployments.
MS has a hotfix for that case: http://support.microsoft.com/kb/936867.

But I was not doing any Incremental deployments, I just wanted to export one single file from a site. Also, I did not have the time to request, wait and install the Hotfix so I tried something else:
Delete all content from the Style Library, and it worked.

Just a cut-and-paste everything to your local machine, refresh the browser (just to be sure) and put everything back in place. Of course you will lose any version data, but thats a fair trade-off.

The issue is also related to the Site Image gallery and other site-level-galleries, so you might want to try resetting them as well.

Copying VSTO Infopath project can save you a lot of time, but it can also bring you a lot of problems.

Follow these steps to avoid problems:

• 1. Copy the project directory, change the name and add the new project to your solution
• 2. Rename the project (from VS)
• 3. Open the manifest.xsf in the XML Editor (Open with..)
• 4. Update the name attribute in the xsf:xDocumentClass element
• 5. Update the projectpath attribute in the xsf2:managedCode element
• 6. Update the initialDocumentName attribute in the xsf:initialXmlDocument element
• 7. Open template.xml and update the name attribute in the mso-infoPathSolution element
• 8. Update the AssemblyProduct in AssemblyInfo.cs
  
  [Optional]
• 9. [optional from here] Rename the assemblies and namespaces
• 10. Update the Assembly name and the Default namespace in de project properties
• 11. Update the Namespace in your code (note the partial classes!)
• 12. Delete old dll's and debug files from your project
• 13. Open manifest.xsf in de XML Editor (Open with..)
• 14. Delete the xsf:file elements to the old dll en debug files
• 15. Rebuild your project