IISReset- perhaps the first lesson every SharePoint developer and administrators learn.
But when we start to do extreme programming(really lol), we eventually forget to do this.. cool lemme come to the meat of the subject..
Last week I have to support from development side for a uat deployment of our new solution. Every thing worked well in my environment as always. My development environment is a standalone farm. testing, uat and prod are medium farms..
We deployed the code. loaded the site..Some code error..ahhh.. i could see clearly from the error that the new code is not referred by the page. We did redeployment as I insisted confidently that Web hosting team didn't do the deployment as I specified in the install notes. Whenever something go wrong then its other mistake. lol...
So we deployed the solution..again same error. Now Web hosting team hit me back stating its my error.
on multiple refresh of the page, i saw the site loading correctly on few instances. ahhhh i caught the culprit. "DLL caching". I asked to do IISReset on all the WFE's. It worked.
So whats the issue.
Whenever we deploy a new code which has a dll we probably need to do a IISReset.
You know why, SharePoint when hosted in IIS caches the dll from GAC and renders the page from it. So we have to tell the GAC to take the new dll from GAC after new deployment of our code.
Do we need to do IISReset on all new deployment. Answer is no.
1. When we do partial trusted solution SharePoint automatically picks up the new dll from the bin. We dont need an IISReset.
2. When we deploy features, we dont need it unless and until it doesn't has any code.
Most of the prod servers doesn't allow us to do IISReset. Then how to tell my IIS to take the new dll from the GAC.
Use the below script to refresh the application pool.
But when we start to do extreme programming(really lol), we eventually forget to do this.. cool lemme come to the meat of the subject..
Last week I have to support from development side for a uat deployment of our new solution. Every thing worked well in my environment as always. My development environment is a standalone farm. testing, uat and prod are medium farms..
We deployed the code. loaded the site..Some code error..ahhh.. i could see clearly from the error that the new code is not referred by the page. We did redeployment as I insisted confidently that Web hosting team didn't do the deployment as I specified in the install notes. Whenever something go wrong then its other mistake. lol...
So we deployed the solution..again same error. Now Web hosting team hit me back stating its my error.
on multiple refresh of the page, i saw the site loading correctly on few instances. ahhhh i caught the culprit. "DLL caching". I asked to do IISReset on all the WFE's. It worked.
So whats the issue.
Whenever we deploy a new code which has a dll we probably need to do a IISReset.
You know why, SharePoint when hosted in IIS caches the dll from GAC and renders the page from it. So we have to tell the GAC to take the new dll from GAC after new deployment of our code.
Do we need to do IISReset on all new deployment. Answer is no.
1. When we do partial trusted solution SharePoint automatically picks up the new dll from the bin. We dont need an IISReset.
2. When we deploy features, we dont need it unless and until it doesn't has any code.
Most of the prod servers doesn't allow us to do IISReset. Then how to tell my IIS to take the new dll from the GAC.
Use the below script to refresh the application pool.
Option Explicit
'*** spsapppoolrecycle.vbs
'*** Script to recycle Sharepoint Portal Server application pool
'*** For use when deploying updated version of Webparts in the GAC
'*** Author: Michael Christensen, mac@landscentret.dk
'*** Provided AS IS with no warranties
'*** Heavily based on this posting by David Wang:
'*** http://tinyurl.com/4k26n
Const WEBSITEID = 1
Dim objApp
Dim AppPoolId
Dim objAppPool
Set objApp = GetObject("IIS://localhost/w3svc/" & WEBSITEID & "/root")
AppPoolId = objApp.AppPoolId
WScript.Echo "AppPoolID: " & AppPoolId
Set objAppPool = GetObject( "IIS://localhost/w3svc/AppPools/" + AppPoolId )
objAppPool.Recycle()
WScript.Echo "AppPool recycled."
The script assumes that Sharepoint is installed on the virtual server with ID 1. This will usually be the case, otherwise the actual ID could probably be determined programmatically.
Probably next time when you deploy the new code,,think whether is necessary to do an IISRESET after deployment.
