I was customising a people search result web part this week and couldn't figure out why the mobile phone field was not rendering in the results. I could see it was in the AD properties, was making it through user profile import and then helped it through to managed metadata in the search results, I even checked the raw XML for the search results which showed it there as well. So I was down to checking my XSLT, I had camel cased the name of the field in my select code, as is my habit with coding to make it easily readable, but the XSLT was looking to match the case returned by the search results which was all in lower case.

A quick crrection and refresh and they all appeared as they should. Another little puzzle solved...

I often go to execute a stsadm command and find it is not in the path on the server I am working on, so I looked for a while of a way of adding it permanently through powershell and then realised it's a straightforward task with .NET code. The following will add the BIN folder within the program files structure to the PATH environment variable at local machine level so that all users will benefit.

   1:  $envpath = [environment]::GetEnvironmentVariable("Path","Machine")

   2:  $binpath = $env:Programfiles + "\Common Files\Microsoft Shared\web server extensions\12\BIN"

   3:  if ($envpath.contains($binpath) -ne $true ) {

   4:  $envpath = $envpath + ";" + $binpath

   5:  [environment]::SetEnvironmentVariable("Path",$envpath,"Machine")

   6:  Write-output "BIN Path added."

   7:  }

   8:  else

   9:  {

  10:  Write-output "BIN Path already added."

  11:  }

I have added a check to not add it if it is already present as the traditional method of using

SET PATH=%PATH%;C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN

ends up with multiple copies of the BIN path in the variable and only applies for the current session.

One of the main complaints (?) of developers is that they have to undertake Sharepoint development inside of a virtual machine, or on a server. Personally, I don't find this a problem as long as you are not working against a live server!. Our new development environment (that I'm sure Iain will blog about) is almost entirely virtual, development, staging and test.

Although not supported by Microsoft, there are a few options to get around this....

a) Install WSS on Vista

Yes it can be done (although I haven't personally tried it yet) and the guys at Bamboo have posted an article on this

b) Install the various assemblies, XSD files onto the client PC as noted here (this is the route I've taken with the laptop so that I dont have to always work inside Virtual Machines)

The downside of both of these is that debugging gets more difficult - you will have to configure remote debugging on the server, plus some of the tools (such as WSS extensions) won't install or run correctly

I still have some clients running WSS 2. As good IT guys, the IT team patched their WSS 2 farm with Service Pack 3.

Concurrently, I was putting together some dataview web parts to render some web services. Everything worked great on the development virtual server, but try as I might, I could not get the webparts to render for nayone other than administrators on the live servers.

Eventually, we tracked down the problem. SP3 has broken some of the dataview functionality, as noted by SporkBomb. It took a lot of head scratching and crawling the web to find this. (The development machines are were still at SP2  )

Microsoft has issued a hotfix to rectify this, but you will have to contact your support centre to obtain the fix. If the blogs are anything to go by, this could be a painful hotfix...

One of the questions we are most frequently asked by our clients is whether they should be using Windows Sharepoint Services (WSS) or Microsoft Office Sharepoint Server (MOSS).

The normal tradeoff is between licensing cost & functionality required.  In some scenarios the client can achieve their desired requirements through a combination of WSS and some customisation to deliver the components which would have come with MOSS.  In other scenarious the additional functionality delivered by MOSS clearly outweighs any additional licensing costs.

For those that don't know the difference, WSS is the foundation for MOSS and delivers a lot of the core functionality in Sharepoint such as team sites, document management, collaboration capabilities, search and so on...MOSS then adds an extra layer on top of WSS and provides a significant level of additional functionality.

The main areas that we find usuall 'sell' MOSS are:

• Content Publishing
• My Site Functionality
• Extended Indexing and Search Capabilities
• Content Targetting through Audiences
• Ability to Integrate into Back End Applications
• Infopath Forms Services

There is a more detailed comparison here or if you contact us we can send you a more detailed spreadsheet with detailed functional differences.

We've been doing a lot of work recently with Sharepoint and InfoPath, both the client application and Forms Server.

Data Connections are a great way of centrally managing the connections to external data sources, whether they be Sharepoint Lists, Webservices or other. However, like most things, they need some thought and planning.

A good introductory article has been posted by the Infopath team http://blogs.msdn.com/infopath/archive/2007/03/21/infopath-data-connections-part-1.aspx

Some quick things that we have found with connections....

a) Create them first (create a .udcx file) and submit to the server before starting work on the forms.

b) Create them using either this template (courtesy of the InfoPath team) or another editor. Although you can use the InfoPath connection wizard to convert connections on the server, we encountered some problems with this approach in the earlier days of forms development.

c) When developing for InfoPath client, be mindful of the need for central connections. The client form will download the connection details each time it is opened adding potentially several seconds to each tiem a form is opened. This was found to be not so much of an issue on forms server.

d) Consider if a data connection is really necessary or if, for simple lists (e.g. drop down selections) a 'hard coded' set of options is more efficient.

e) Store the data connections in a high level location (so they are accessible by forms at any lower level of a MOSS heirarchy) and keep the connection paths as server relative

f) Consider using 'read' type webservices for submitting data to external locations, rather than 'submit' type services. We found submit services to be greate where all of the InfoPath form had to be submitted, but using read type services allowed us to submit small sections of data, and even use button rules rather than code.