When you update or retract a SharePoint solution, it's supposed to automatically restart or recycle any affected application pools on all servers on the farm.

For web application pools, this appears to be largely true (though I've seen exceptions). However for service application pools, it's definitely not, and this essentially means that after updating a SharePoint solution, you must manually recycle/restart the service application pools, or you get all sorts of potentially weird behavior because code running under the service application pool is still using old versions of your assemblies (one obvious error that happens frequently for us is "The located assembly's manifest definition does not match the assembly reference", but there are far more subtle possible errors).

My question is - why would this be true, and is there a good way around it? Even if it's just to accept that customers must use our provided install tool to upgrade and the install tool does the correct thing, it would seem quite a significant amount of code is required to search all servers in the farm and request them to restart their application pools (I do have some code, but haven't tested it yet).

Anyone else experienced this?


1 Answer 1


is it farm solution which is going to GACdeployment?

In that case an IIS reset will trigger in all servers in farm, that's what we expericeing all the time.

here is the offical statement "Initially, the package manifest is parsed to find assemblies, application pages, JavaScript, and other files that are not part of a Feature. These are copied to the locations specified in the manifest. All files contained within a Feature are copied to the Feature directory, a subdirectory of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end web servers; the reset then deploys the files and restarts Internet Information Services (IIS)."

But is the solution scoped to the web app only and deploying into the Bin folder of web app then i think only app pool will recycled.

Best practices, always reset IIS on the farm to fix the issues, if not too many different apps...off course select the off peak hours.

also check this: http://www.jeremytaylor.net/2011/03/10/sharepoint-solution-deploy-retract-upgrade-what-causes-an-your-sharepoint-farm-to-go-offline-iisreset-web-server-outage/

  • One of the solutions is globally deployed. As I understood it that would recycle all application pools, but it only appears to recycle web application pools, not service application pools. Iisreset on its own only affects the current server - you have to call it with the name of each server in the farm if you need it on all servers. I can hardly see how it can be considered "best practice" given a) it interrupts availability for services that have nothing to do with our solution and b) it causes very long delays loading up the first page after doing so. Jun 8, 2014 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.