SP 2013 - How to modify webpart in deployed solution

Question

I'm a ASP.Net developer very new in SharePoint development (and english is not my native language).

We have just one Sharepoint Project, which contains all the WebParts that users use. When we have a bugfix on a WebPart, the correction in production environment occurs in the following steps:

1. Uninstall the current solution; - Uninstall-SPSolution
2. Remove the uninstalled solution; - Remove-SPSolution
3. Add the new solution (the new .wsp package generate by VS with the bugfix); Add-SPSolution
4. Install the added solution; - Install-SPSolution

In this process, the production portal stays offline by 5~10 minutes - what is inadmissible, given the criticality of the portal.

---

The question is: How could I make small corrections and bugfixes (in WebParts, for example) without uninstalling and removing the current solution, keeping the production site online during the process?

Any recommendations are welcome

---

Edit1 (more informations): In fact, our WebParts code behind just interfaces with other referenced projects. In most cases, the bugfix occurs on a core library, rather than the webpart code. So, in this case, I just need to update that dll's.

Answer 1

Unfortunately in this scenario that you described there is no way to update the package without the end user notice the maintence.

In a mid-term solution, i strongly recommend you to gradually migrate your solutions to a Sharepoint Provider-hosted Add-Ins/Apps, then you can make your changes without stop the entire site.

Here some links to help you:

Choose patterns for developing and hosting your SharePoint Add-in https://msdn.microsoft.com/en-us/library/office/fp179887.aspx

SharePoint Add-ins https://msdn.microsoft.com/en-us/library/office/fp179930.aspx

Hope it helps

Answer 2

There is an easier way to update a farm solution, and that is the Update-SPSolution cmdlet. If your changes or bugfixes are primarily in the code-behind of the webpart, this will successfully update the .dll or any .aspx/.ascx files associated with the webpart without having to do a full retraction and re-installation. Please note that the documentation says:

Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively.

Addressing the second part of your question though, about site availability: I have found that even when using Update-SPSolution there is some sort of IIS application pool recycling, or maybe even a full IIS Reset that is triggered automatically, resulting in sites being offline for several minutes as you describe.

Our current process now is that if I have an update to be applied, I package up the WSP and put it on a file share, send an email to my Farm Admin telling him the location of the updated WSP, and he runs the Update-SPSolution after business hours when the downtime will not affect users.

Not ideal, but he and I are both comfortable with it and it leaves the sites up and available for users when they need to be working.

Answer 3

Dylan's answer is correct - you need to reset IIS so that the Web Worker Processes can pick up the new DLLs.

I'd also like to share a method I've used to get around this in the past - if your bug fixes are only asset-related (i.e., JavaScript, CSS) and are deployed to the Layouts mapped directory, then you can edit the files by browsing to the Layouts directory on the Web Front End Servers, which is located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS.

Once you make a change to a file here, however, users typically need to Ctrl+F5 to clear the cache and see the change. You can get around this by making the references to these files uncacheable, by adding "?random=XXXXX" where XXXXX is a random number to the file path or some similar strategy.

If you need to change the UI of the web part dynamically, consider using JavaScript templating and web services combined with the above approach to limit your dependency on backend code.

Depending on what's in your Web Part, you could also move towards the Add-In model and develop a provider-hosted app or a SharePoint-hosted app that uses the CSOM to accomplish your functionality. Those are of course both significant undertakings but in line with where Microsoft wants us to go... :)