Sharepoint Developer: Provider Hosted App -Windows Azure Hosting (Post1)

Provider Hosted App -Windows Azure Hosting

Provider Hosted App:

Provider hosted apps are applications that run in a server that is external to SharePoint's. It has its own infrastructure and the Provider is responsible for keeping it running. They allow you to use Server Side code and uses the .NET CSOM (not the Microsoft.SharePoint.dll [technically you can host a Provider hosted app in the same server as sharepoint with an app pool that has the security requirements to access SharePoint's server side components.

Provider Hosted app have its SharePoint Hosted counterpart, earning itself an AppWeb and running client side code that has support from SharePoint like the ListView Controls and owning content that are "isolated" from the rest of the site collection.

Provider-hosted add-ins in Azure Web Roles

You can host a provider-hosted SharePoint Add-in on a Microsoft Azure web role instead of a web application (whether the web application is on-premises or an Azure Web Site). An Azure web role is, essentially, a website that's based on Internet Information Services (IIS) and hosted on Azure. You can take advantage of the hosting services and scalability of Azure web roles. You can also enhance the performance and usability of your SharePoint Add-in, especially if the add-in is heavily used or demand for it changes over time. If the SharePoint Add-in ever requires more server resources, Azure can dynamically allocate them to the add-in.

Pre-requisites:

SharePoint online account
Azure account

Creating Sharepoint-Addin Project:

App for SharePoint is now as SharePoint Add-in (in VS2015)

Open VS2015 and Create a project with SharePoint Add-in

Mention the SharePoint online site which you already have and select Provider Hosted Application (We will host app in Azure)

Select the application type as for your need, am using normal ASP.NET web application in this sample.

To host the app in Azure, please configure authentication settings to Use Windows Azure Access Control Service

Now our solution File is Ready, this consists a web application and a SharePoint app project as highlighted in below image.

Setting up App in Azure for hosting:

Create an App by clicking App services on the Homepage and click on +Add

Provide details for the app and create the app in Azure environment.

Now your app listed in the app services tab. You can see the details of the app over there.

Now we need to register the app in our target SharePoint online site (Which we mentioned during creation of the Visual studio project/solution).

1.Navigate to “../../_layouts/15/Appregnew.aspx”

2.Generate ClientID and Client Secret

Navigate to http://<SharePointWebsite>/_layouts/15/AppRegNew.aspx on the tenancy or farm.

AppRegNew page form

Enter values for the follow form fields:

Add-in ID - Also known as client ID, is a GUID that can be generated (when you choose Generate) or pasted into AppRegNew.aspx. The value must be unique for each add-in, and must be lower case.

Add-in Secret - Also known as the client secret, an opaque string. It is generated on the AppRegNew.aspx page by using theGenerate button. The following is an example of an add-in secret: xvVpG0AgVIJfch6ldu4dLUlcZyysmGqBRbpFDu6AfJw=.

Title - A user-friendly title; for example, Contoso photo printing add-in. Users are prompted to grant or deny the add-in the permissions that the add-in is requesting. This title appears as the name of the add-in on the consent prompt.

Add-in Domain - The host name of the remote component of the SharePoint Add-in. If the remote application isn't using port 443, the add-in domain must also include the port number. The add-in domain must match the URL bindings you use for your web application. Do not include protocol ("https:") or "/" characters in this value. If your web application host is using a DNS CNAME alias, use the alias. Some examples:

www.contoso.com:3333
www.fabrikam.com

Redirect URI: - The endpoint in your remote application or service to which ACS sends an authentication code. Strictly speaking, SharePoint Add-ins don't use this value. The redirect URI is required for web applications that are launched outside of SharePoint and that use
the Authentication Code flow to get authorized access to SharePoint data. The Redirect URI is ignored for true SharePoint Add-ins (which are launched from SharePoint and use the Context Token flow). The Redirect URI is usually the same page, controller method, web service method that requested the authentication code from ACS, but it can be a different endpoint. The endpoint must have logic that gets the authorization code from the HTTP Response that is sent by ACS and then uses that code to request an access and refresh token. For more information, see Authorization Code OAuth flow for SharePoint Add-ins. The form requires that you enter a valid value even for true SharePoint Add-ins, although it is not used.