Saturday, February 23, 2013

WebPart Life Cycle in different PostBacks


On Page Load

  1. Constructor
  2. OnInit
  3. OnLoad
  4. ConnectionConsumer method is called if web part is connectable (sets the connection providers interface in the webpart)
  5. CreateChildControls
  6. OnPreRender (if your web part is connectable you would typically call the connection provider here to retrieve data)
  7. SaveViewState
  8. Render
  9. RenderChildren
  10. RenderContents

On 1st Postback
(PostBack click handler sets ViewState via public Property)

  1. Constructor
  2. OnInit
  3. CreateChildControls
  4. OnLoad
  5. PostBack click handling
  6. ConnectionConsumer method is called if web part is connectable (sets the connection providers interface in the webpart)
  7. OnPreRender (if your web part is connectable you would typically call the connection provider here to retrieve data)
  8. SaveViewState
  9. Render
  10. RenderChildren
  11. RenderContents

On 2nd Postback
(PostBack click handler sets ViewState via public Property)

  1. Constructor
  2. OnInit
  3. LoadViewState
  4. CreateChildControls
  5. OnLoad
  6. PostBack click handling
  7. ConnectionConsumer method is called if web part is connectable (sets the connection providers interface in the webpart)
  8. OnPreRender (if your web part is connectable you would typically call the connection provider here to retrieve data)
  9. SaveViewState
  10. Render
  11. RenderChildren
  12. RenderContents
Note that during the 2nd postback, LoadViewState, is called, since in the 1st postback the click handler sets the value of the ViewState backed public property.

Thursday, February 21, 2013

Where are Assemblies in Sandboxed Solutions Deployed?

Hi All,

Sometime back I started working on SandBox Solutions. I came across many issues and situation in terms of restrictions and Resource Point Utilization.

When I tried creating a Visual WebPart then I neede PowerTool VS extensions inorder to make it work.
Hence I realized that in sandbox solution, we are not dealing with file system. It its not that way then where my assemblies reside.

Then came across a msdn article which enlightened me with following facts.

The assemblies in the sandboxed solution are included in the solution pkg i.e. ".wsp" file, and the pkg is deployed to the site collection's solution gallery.
When a sandbox solution is accessed for the first time i.e. when a user access the webpart from sandbox solution, any assembly in the solution is extracted from the pkg in the gallary and copied to the file system of the server that is handling the sandboxed request. The location is
c:\ProgramData\Microsoft\SharePoint\UCCache

The executable of this service is SPUCHostService.exe. The server that handles the sandboxed request is not necessarily the front-end web server that is handling the initial HTTP request.
The Microsoft SharePoint Foundation Sandboxed Code Service can be run on back-end application servers in the farm instead. Because the sandboxed user process (SPUCWorkerProcess.exe) cannot copy anything to the file system, the copying is done by theMicrosoft SharePoint Foundation Sandboxed Code Service.

The assemblies of a sandboxed solution do not stay in the file cache perpetually. When the user session that accessed the solution ends, the assemblies stay in the cache for only a short time, and they may be reloaded from there if another user session accesses them. Eventually, if they are not accessed, they are removed in accordance with a proprietary algorithm that takes into account how busy the server is and how much time has gone by since the assemblies were last accessed. If the sandboxed solution is used after that time, the assemblies are extracted again and copied to the UCCache.