For the code sample yesterday I instantiated the ContentContext with the line
ContentContext contentContext = new ContentContext();
Using the default constructor like this implies that the code is run on a server which has FAST Search for SharePoint installed as it will read the configuration file from %FASTSEARCH%\etc\Admin.config.
When using the ContentContext object from within SharePoint you have to go via the FASTAdminProxy property on the SearchServiceApplicationProxy object from the FAST Query SSA. If this sounds greek to you, the code below might shed some light.
var ssaProxy = (SearchServiceApplicationProxy)SearchServiceApplicationProxy.GetProxy(SPServiceContext.Current); if (ssaProxy.FASTAdminProxy != null) { var fastProxy = ssaProxy.FASTAdminProxy; // Get a reference to the ContentContext via a WCF proxy ContentContext coll = fastProxy.ContentCollectionContext; coll.Collections.AddCollection("notes", "Lotus notes connection"); }
The FASTAdminProxy reads it’s WCF configuration from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\FASTSearchAdmin\ContentCollectionService\client.config.
But, now we encounter yet another bug. The factory class which creates the proxy has a readonly member “ServicePostfix” which returns the name of the WCF service endpoint. For the ContentContext it returns “ContentCollection.svc”.
Microsoft.Office.Server.Search.Administration.FASTAdminProxy
ContentCollectionServiceFactory ServicePostfix
But on the FAST server the endpoint is named “ContentCollectionService.svc”, so we get an error that it cannot connect to the WCF service. The fix is simple and involves copying the file
%FASTSEARCH%\components\admin-services\contentcollectionservice.svc
over to
%FASTSEARCH%\components\admin-services\contentcollection.svc