Updating Provider Hosted Add-Ins

[Deleted]

I have a VS solution for creating Provider Hosted Add-Ins (internal IIS server) for a new Sharepoint Online (development) site collection, but I'm having issues when adding new ClientWebParts.

After creating a new one in VS, I publish the web solution to IIS, then press F5 to build and deploy the apps to Sharepoint Online, but my previous Web Parts are removed from any pages I have added them to. Is this by design? Is there another way I can deploy updates without the app being retracted/uninstalled first?

I have tried to edit the Deployment Configuration Settings to remove the Uninstall SharePoint Add-In step but my updates do not get applied.

[#2 · Accepted solution]

This is by design. The solution creates a new clientId, re-packages and re-creates a new .app package in your site. During this process it re-tracts the current solution and installs the solution.

The only time this wouldn't be the case is if you are working on the web project files. 

[#3]

Eventually I could have several dozen web parts that will be gradually built over time and added to SP as I go. It's not realistic to have to re-add each web part to every page at every update.

Am I going about this the wrong way?

[#4]

@Deleted I would have a place where you can deploy the add-in (not your development environment). Where the web parts you currently actively working on can live. Think of this as your staging environment.  

In most scenarios, you are working with 1 web part at a time, no? I would use your development environment as you are today. When a web part is "done", just deploy the app to your tenant and install a version in a another site collection. That way you can always have a configured site, with configured web parts. 

On a side note, is there any reason you are using Add-Ins instead of using the SharePoint Framework? Not that add-ins are going away right now, but SharePoint Framework is a much better way to implement web parts in SharePoint Online, that work both in classic and modern pages. 

[#5]

I am working on one at a time usually, but they are just small ASP WebForms that display data from our internal databases (calendars, grids, charts, etc) so I can knock out a few a week. I'm not excited about being stuck using IFrames but I have been able to make it work. I'm not interested in using built-in SP lists, forms, etc. which is why I didn't think client side SPFx would work for us. 

I'm not sure how having a second dev site (has to be dev site to side-load apps, correct?) would help. We are only dedicating (1) site to our internal business data pages. Maybe I can break the web parts up into seperate apps, but that means having multiple IIS virtual directories which sounds messy.

[#6]

@Deleted The reason I ask, is that SPFx has built in support for third part web APIs. If your company is planning on expanding how much data you bring into your environment, you may start thinking about using SPFx + a Web API to grab the content.

Generally speaking the Provider Hosted Add-In model is quite clunky, and obviously, having to develop in IFrames is a huge pain. Using SPFx and the AADHttpClient, you could build your Web API that does all of your on-premises data access, while at the same time building your web parts in a modern framework like SPFx - giving you the best of  both worlds; On-premises data access and responsive/modern web parts w/out Iframes.