Lesson Learned on SharePoint Service Applications

If you’re setting out on writing your own SharePoint service applications, there is an important lesson that you should keep in mind (instead of learning it the hard way): ensure that all of your proxy, application proxy, service, service application, and service instance classes have public parameterless (default) constructors.

Otherwise, you’ll have a heck of a time starting, instantiating, and uninstalling services with lots of MissingMethodExceptions and “{class} cannot be deserialized because it does not have a public default constructor” error messages.

Oddly enough, one thing I’ve learned from this is that the STSADM commands are often more “powerful” than the equivalent Powershell commands.  For example, Remove-SPSolution, even with the -force parameter, still failed with the aforementioned exceptions.  On the other hand, stsadm -o deletesolution {name} -override seemed to work fine.  Puzzling, for the moment, but it got the job done.  Similarly, stopping a service application that’s AWOL (stuck on the processing screen) can be accomplished with stsadm -o provisionservice. Deleting it can be done using stsadm -o deleteconfigurationobject (though this one does seem to have side effects…).

Seems that Powershell is still a second class citizen when it comes to basic SharePoint command-line management.

But in any case, if you set out building your own service applications (<rant>and damn it Microsoft, can’t you put some better examples out there?!  Even the few that are out there are convoluted, missing key details, hard to follow…</rant>), be sure to include public, default, parameterless constructors.