How to reliably detect MOSS or WSS at runtime
Our support team faces different SharePoint based ‘customer challenges’ on a daily basis. It will comes as no surprise that no two SharePoint deployments are the same, but sometimes we are really baffled by what we encounter.
Recently we came across a SharePoint environment that had a problem with the fancy ‘Browse’ button that allows users to select a destination library to store documents converted by our PDF Converter for SharePoint. The thing is, this environment was running WSS and not MOSS and as WSS does not support this fancy feature we only display this button on MOSS systems.
Shiny Document Library picker
Our MOSS detection logic is based on a common pattern, which is to check for the presence of the MOSS only OssNavigation feature. As this particular WSS environment has this feature installed it was incorrectly detected as a MOSS installation, resulting in problems when someone would press the browse button.
Further investigation shows that checking for OssNavigation is not a reliable manner of detecting MOSS as this feature is also installed by the free Microsoft Search Server 2008 Express, which can be installed on top of WSS.
To cut a long story short, we have updated our solution to check for 2 MOSS specific features before deciding if a SharePoint installation is MOSS or WSS. The code is as follows:
/// <summary> /// Method to find out if a SharePoint installation is MOSS or WSS 3.0 /// </summary> public static bool IsMOSS() { SPFeatureDefinitionCollection features = SPContext.Current.Site.WebApplication.Farm.FeatureDefinitions; if (features\["OssNavigation"\] != null && features\["Publishing"\] != null) return true; else return false; }
Clavin is a Microsoft Business Applications MVP who supports 1,000+ high-level enterprise customers with challenges related to PDF conversion in combination with SharePoint on-premises Office 365, Azure, Nintex, K2, and Power Platform mostly no-code solutions.