Job done. Many thanks.

Browser
I’m using IE9, and I tried every “Compatibility Mode” it had under Dev Tools (F12). I also tried adding the production site to my Trusted Sites and Intranet Sites. I also lowered my security settings as low as they would go and still nothing.
I also tried Firefox 4 and Chrome – neither one worked with the production site, but did work with my DEV site.

WebService.asmx
I played a thousand variations here. I tried everything from changing “Namespace := “myWSNamespace” to blank, my webservice’s URL, to wrapping the class in a Namespace.
Some sites suggested you had to specify the namespace because it’s part of how you reference the service in your javascript code. Didn’t work for me.

_
_
_
Public Class myWSClass
Inherits System.Web.Services.WebService

_
Public Function isActive() As String
Return “True”
End Function

Script Manager
I used the following scriptmanager. It didn’t matter if the webservice was in a folder called “services” on the root or in the same folder as the javascript code. It did NOT work.
All folder and subfolders had ASPNET user account with FULL permissions. Still nothing.

Javascript
Finally, the problem child. The following ExecuteProcess() function is called by an HTML button. I played for hours with the namespaces.
Some sites say you have to follow the following format: Namespace.Class.Function()
I mix and matched namespaces, class names and then some. In the end what worked was Class.Function(). Not sure if this is a .Net 4 thing (versus a previous .Net framework), but that’s what worked for me.

function ExecuteProcess() {
myWSClass.isActive(SucceededCallback);
} //End Function

function SucceededCallback(result) {
var strWSResults = result;
} //End Function

But it still didn’t work in production! So here are two more things I did that eventually got it to work:

Upon closer look at the “View Source” I noticed this line:

This means the browser was linking to the service via the following URL: http://yourdomain.com/myWSClass.asmx/jsdebug The URL downloads a JS file that Javascript uses to talk to make calls to the webservice.
When i went directly to the URL, my devbox prompted me to download a JS file, but in production it wasn’t, instead it was generating some error message.

I researched the “jsdebug error” and found this article at stackoverflow.com
http://stackoverflow.com/questions/5382239/request-for-wstestservice-asmx-jsdebug-returns-500-error-on-server-fine-in-devel

The poster was able to solve the problem by re-registering .Net 4:
C:WindowsMicrosoft.NETFramework64v4.0.30319>aspnet_regiis -i

OK! This ALMOST got me there. I found another article that clued me into adding FULL namespaces when calling assemblies in webservices.

So even though my webservice code had “IMPORTS SYSTEM.DATA” and was compiling correctly, it was still erroring in production. Not sure why – but i went ahead and changed all my
ds = New DataSet
to
ds = New System.Data.DataSet

I added full namespaces to ALLLLL the different places in the webservice and FINALLY it all works in production.
Again, not sure which one specific thing I tried fixed it, but hopefully this will help you.

Carlos

We did discuss that approach with our PSS engineer but the solution wasn’t scalable for several reasons which I’ll list below

Our client’s farm is effectively multi-tenant, meaning we have different FAST search centers, one for each internal customer. This would require manual updates to the search results for each new search ui
The xml passed back to the web part has the specific file name for each icon included. We would need to name explicit icon files whose name *could* change in the future. Unlikely, but possible. Same goes for a FAST CU adding indexing capability over new file types (you’d need to update the xslt)
The xslt for Local Sites Search is not customisable (this goes to a page called something like /_layouts/OSSSearchResults.aspx)

It would be possible to workaround in specific circumstances, but we felt the long-term approach for the platform justified the Custom Pipeline extension.