March 2007 - Posts

• Excluding Content Types from Search Results

  I received a question recently about excluding certain items from the search results and thought it was worth a post. There are two main options that I thought of when asked. Firstly, editing the XSL on the Core Results web part that controls the format of the returned results. This works fine for actually hiding the items, for example, you can wrap the results display part of the XML in an xsl:if to exclude the current item: <xsl:if test="contenttype='Contract'"> (assuming you have contenttype included in the Selected Columns XML within the Core Results web part) The reason why this is not such a great idea is that the web part that displays the results statistics will still include the items in the count and seeing as you cannot access the hidden control that binds the web parts together and can't change the output of the Statistics web part you cannot change that. The best way is to limit the results based on Scope. Either by creating a separate Scope that can be used when searching or by modifying the default Scope used, ie. All Sites. First you need to make sure that the Managed Property you want to limit the Scope with is allowed to be used in scopes. To do this go to Central Admin, Shared Services Admin for the SSP in question, Search Settings, Meta-data Property Mappings. Then edit the Managed Property and check the 'Allow this property to be used in scopes' check box: Next, you need to add a new rule to the Scope to Exclude the items based on the value for the Managed Property. Go back to Search Settings, Click on View Scopes and then edit the scope you want to change. Click Add new Rule and create a Property Query rule that is set the to Exclude items where the property you modified above is equal to the value you want to exclude. For example to exclude Folders from search results: (note that if you're interested in excluding folders, the above works in SharePoint, but you'll need to do something more for file shares - see Scott Jamisons's post) Then make sure that you run the Update Scopes option so that the change to Scope takes effect. I'm not 100% sure, but I think that if you have not had a Scope based on this Managed Property (or it might be if you enable the Managed Property for use in Scopes) you may need to do a Full Crawl to have this all work properly. Also, if you check the 'Show Scope Picker' option in the Advanced Search Box web part, and you have created a new scope for the Exclusion to apply to, the user can select that Scope when searching.  Be aware when doing all this that the will be a price to pay somewhere if you have a lot of Scopes defined in this way (even if it's only in confusing the user!), and that if you need really custom restrictions, perhaps you are better off with a custom search solution tailored for the way that the users need to search!   Posted Mar 28 2007, 10:46 PM by adrh with 1 comment(s)

• Querying the SharePoint Change Logs

  SharePoint 2007 keeps a record of all changes made to data, users, permissions, sites etc in a Change Log which you can access via the object model. This is actually how the indexer figures out what to crawl as part of an incremental crawl. You need to be aware that the log history length is controlled by configuration available to server admins so it is possible that the changes you are looking for might have dropped off the log. And this is why there is a caveat around incremental crawling in Indexing... For example, say I wanted to get all the items that have been added, modified or deleted from a list:   //Create a new query, and set it not to return anything by default.  SPChangeQuery listQuery = new SPChangeQuery(false, false);  //Now set if to return the types of info we want.  //In this case item changes of type Add, Delete and Update...  listQuery.Item = true;  listQuery.Add = true;  listQuery.Delete = true;  listQuery.Update = true;  //Get the changes that match the query.  SPChangeCollection changesCollection = currentWeb.GetChanges(listQuery);  //Do something with them.  foreach (SPChangeItem currentChange in changesCollection)   {      ...    } The code above will return ALL changes in the log for list items in the specified Web. A Change Token is returned in the as part of the SPChangeCollection and can be passed to subsequent calls to GetChanges to return changes since the last time you checked. Meaning you can perform synchronisation operations in your own apps. To get the last change token:     SPChangeToken lastChangeToken = changesCollection.LastChangeToken; Set the queries start token to the last change token we had:     listQuery.ChangeTokenStart = lastChangeToken; And then call the GetChanges method as above.   Posted Mar 22 2007, 12:15 AM by adrh with no comments

• SharePoint Alternate Access Mappings

  I came across the second part of Troy Starr's Trilogy on Alternate Access Mappings in SharePoint 2007. It's a great series from an Administrators perpective on what they are and why you need them. I recently 'stumbled' upon them when writing some code that accessed a site based on the URL. When I passed the internal name to the web service everything worked fine, by FQDN, IP Address, or externally accessible URL did not work (note I didn't realise that at THAT stage neither would all of the external links - see Troy's post). Once I added alternate access mappings for all the possible ways people could pass a URL to the site to SharePoint all was well. Whatever you use as the URL when setting up your new server (and therefore becomes the URL you see when choosing application pools in central admin) is the only URL that will work 100% unless you create AAM's!! What I think often happens is people set up a server and answer all the configuration prompts with the internal port 80 details. Then, when they come to go into production, realise that they need another port, or the server to be accessible via SSL, or FQDN and forget that AAM's need to be configured - and it's not until you try to do... SPSite mysite=new SPSite("http://...");  ... where the URL is not mapped that you notice it's broken. Or someone reports that some links don't work... Great post Troy - awaiting Part 3 with antici...........pation.   Posted Mar 19 2007, 10:04 AM by adrh with no comments

• SharePoint Solution Template

  I included a link to a SharePoint Solution Template for VS.Net 2005 in my previous post, which I discovered was a broken link, so I have created my own and you can get it here. It is VERY basic. Just one of our deployment solutions stripped of all the content, which the makecab/build targets setup and the directory structure for things like assemblies, templates and the folders for each file destination. One day I'd like to automate the generation of the DDF file, perhaps via a macro or XSLT. The Project Template will appear under My Templates in the C# area (assuming you put it in the top level templates area under the Visual Studio 2005 directory in your My Documents area). It will prompt you with a warning about possible badness because of the custom build target stuff, but ignore and open normally - unless you don't trust me of course ;-) Posted Mar 16 2007, 01:22 AM by adrh with 3 comment(s)

• SharePoint Solutions Rock!

  Been working pretty hard recently to get our 2007 product releases out the door, and one of the things that has made our lives much easier is the Solution Packaging in SharePoint V3. Our application consists of several features, a web service, custom admin pages and numerous assemblies. The Solution deployment model that V3 uses means we can have one VS.Net 2005 project that handles the deployment of all these pieces across all servers in the farm with one stsadm command and about three clicks in central admin! There are quite a few posts that have details about how to get started, one, which saved me today when I had 'gone it alone' and copied the guts of a collegues Solution project was this one from Andrew Connell - I didn't have the build targets setup correctly! Another that I just found has a download of a VS Solution package template which I will be checking out tomorrow. One little issue that I'm having trouble coming to terms with is when you have several solutions that share files. For example a situation where you have several solutions that have assemblies that inherit from a common assembly. So long as the solutions are deployed together and when one is upgraded they both are everything is fine. However, if you upgrade one and the common assembly is removed by the upgrade process and the second solution is not compatible with the new version of the common assembly, things break. Does anyone know a way around this?   Posted Mar 15 2007, 09:02 AM by adrh with no comments