0

Let's say I have two web application and inside those I have 2 site collections each.

If I deploy a visual web part for sitecollection1 then it does IISRESET which means all sites will be down for a moment.

Isn't this a SharePoint design issue? I mean why would changes in one site should affect other sites?

Improve this question

3 Answers 3

Reset to default
2

Actually, there's no such thing as "deploying a Web part to a site collection". You deploy a Web part with a WSP package; WSP packages (at least ones that contain Web parts) are deployed against specific Web applications. After that the feature containing the Web part is activated per site collection, but "activating a feature" is only a SharePoint logic (i.e. database only) operation, no technical step is made here.

Thus, the real technical deployment happens when you deploy (Install-SPSolution or from the Central Administration) the WSP. Here, "deploying" means copying/pasting files at correct locations. Most of the time (and especially when the WSP contains a Web part) the package contains a DLL (.NET assembly) that's deployed into the GAC (most of the time; could also be deployed into the Web application' bin folder, I'll come to that later).

When a DLL is in the GAC, any process can access and load it. However, the .NET design makes a GACed DLL "un-reloadable" for the entire process-life. It means that if the DLL is changed in the GAC, the process cannot reload the new version until it's restarted. That's a .NET design, not SharePoint's.

That's why SharePoint "decides" to restart the pool (meaning it also restarts all Web applications contained in that pool) to ensure the new version of the DLL is immediatley used (and synced with other updates made in the hive).

That's why, when you update a solution, you have the option to schedule the operation for a later time (-Time parameter) in order for the downtime to occur by night for example.

And that's also a good reason to set your Web applications in dedicated pools.

And also, that's why you can decide to deploy your WSP in "bin mode": you don't put the DLL into the GAC, but into the bin folder of the Web application. You take that decision as a developper, when you create the package in Visual Studio (see the design window of the "package" node). A DLL from the bin folder can be updated live.

And a last note: if your WSP contains a job or a workflow, it means your code may be loaded by the SharePoint Timer service (owstimer.exe). In that case, you must put the DLL into the GAC (not the bin folder of each Web application), so the service can access it. This also means you must restart manually this service after each WSP update (unfortunately, and for a reason I can't understand SharePoint does not restart the service on it own). And this must be done on each server of the farm.

Improve this answer
5
  • This is what I am saying. Unlike Java and PHP etc. where I can simply update the required component and only that will be affected, SharePoint takes whole server down.
    – Frank Martin
    Commented May 1, 2016 at 5:35
  • 2
    You can't compare SharePoint with PHP or Java. If you want to make the comparison you have to compare .Net with with Java/PHP. And .Net is perfectly capable of everything PHP/Java does.
    – Danny '365CSI' Engelman
    Commented May 1, 2016 at 7:09
  • @Frank: as I wrote, this is not because of SharePoint; it's a .NET design. It all comes from the GAC, and the GAC is a shared repository for DLLs, so they can be accessed by all processes on the system. Do you have something similar in PHP, so the comparison can be done properly? Also, there's ways to avoid it, like putting the DLL into the bin folder and set the WSP to not reset servers.
    – Evariste
    Commented May 1, 2016 at 7:26
  • @Evariste So that means there is an option to only deploy solution for a particular web application so that other web applications are not affected?
    – Frank Martin
    Commented May 1, 2016 at 8:33
  • If you deploy to the "bin" folder (as opposed to the GAC; this is a build-time option to set at the package-level in Visual Studio) and set the package to not reset server (also a setting at the package-level in VS), no Web application will be impacted, not even the one using the Web parts. However, this approaches is not possible if your package also contains job(s)/workflow(s).
    – Evariste
    Commented May 1, 2016 at 14:20
0

I don't think it is SharePoint Design issue, It is more IIS issue. When you deploy a solution, it deploys the DLL in GAC folder. IIS can't read those Dll until iisreset performed.Basically, IISreset does two things

  1. clear the memory
  2. reload all the DLLs from the GAC folder.

One thing you can do, During your code you can't set Reset Web Server property to False and then try to stop and start the Web application. Now check if you can get new webpart.

Improve this answer
2
  • This is what I am saying. Unlike Java and PHP etc. where I can simply update the required component and only that will be affected, SharePoint takes whole server down.
    – Frank Martin
    Commented May 1, 2016 at 5:36
  • It is not SharePoint, it is design of IIS. IIS need reset to load new DLLs but from your point of view, Yes at the end It is SharePoint's Issue.
    – Waqas Sarwar MVP ♦
    Commented May 1, 2016 at 5:39
0

It is a usual behavior of SharePoint... When you deploy SharePoint package , it will place the files & it's related DLLs to their appropriate location.. It is necessary to reset is to connect those file with each other to get a reference from different locations ... This is the simple definition from my end to understand why it's necessary to reset the iis..

Happy Coding in SharePoint...

Improve this answer

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.