ASP.NET MVC integration with Sharepoint 2013. Part 1: High-Trusted provider-hosted APP

Hello!

My name is Denis and I work as a senior developer at DoxVision. With this post I want to start a series of articles related to development in the field of SharePoint 2013. They will touch on various aspects of this topic, starting with the capabilities of the basic integration of a Web application and ending with publication in the SharePoint Store. Knowledge of the nuances and pitfalls that I encountered may be useful to those who will face a similar task for the first time.


So, following the chronology, I’ll start by describing how I solved the first task I set: on the basis of the existing ASP.NET MVC application “Docsvision Light Client” to create a new one - “Docsvision client for SharePoint”, which would integrate into SharePoint 2013 and expand Easy client capabilities.

In SharePoint 2013, a new model of Apps has appeared, which is fundamentally different from the old Solutions model. However, you should not be afraid - Solutions have not disappeared anywhere. First of all, you should choose what to use: Solutions or App. The article on MSDN can help with this issue.
Our choice fell on the Sharepoint App, because requirements for integration at that time it was possible to implement through the App. Later, when we decided to integrate into the Sharepoint store, it turned out that it is absolutely correct, because, as you will see in the following articles, Solutions cannot be placed in the Sharepoint store.
Despite all this, no one forbids the use of both approaches. In the following articles I will definitely tell you how we managed to connect the App and Solutions.
')
Let us dwell on our choice - the SharePoint App. According to the documentation, there are several integration options: SharePoint-hosted, Auto-hosted, Provider-hosted. Considering that our application is not the Web API, but the MVC in the classic version and the fact that the application will be delivered on-premises - we decided to use the High-Trusted Provider-Hosted App. High-Trusted means that our Web application communicates with SharePoint through a one-to-one certificate. There is also the so-called Low-Trusted mode - it is used for the SharePoint Store or in the company's local corporate application directory.

So, we all decided, we installed a test site with SharePoint 2013 - and here we are met by the first surprise from Microsoft - it’s impossible to simply create an App and implement it in SharePoint. First we need to prepare SharePoint to use the App. The preparation process is described in detail on MSDN . I will briefly go over the points:

1. Verify that the following SharePoint services are running: User Profile Service Application, App Management Service
2. check the presence of at least one SharePoint user profile and create if there is none
3. create an isolated application domain
4. configure DNS for application domain address

At the 3rd point you need to stop in more detail. What is an application domain? When you install an application (APP) in SharePoint, it is allocated a unique address at which you can access this App-application. The address looks like this: http: // [app prefix] - [app id]. [Domain name] / [site collection path] / [app path] /pages/default.aspx , where app prefix is ​​the application prefix for the entire farm SharePoint; app id - unique identifier for the application; domain name - application domain. The actual domain configuration of the application is the setting of the app prefix and domain name values, and they could be set via Central Administration (Apps -> Configure App URLs), if not for one but - you must first create two new services SubscriptionSettingsServiceApplication and SPAppManagementServiceApplication. Below I will provide a slightly improved PowerShell script for creating these services and configuring application domain settings:

$appDomain = "your app domain" $appPrefix = "your app prefix" $accountName = "your account name" $accountPassword = "your account password" net start spadminv4 net start sptimerv4 $existedAppDomain = Get-SPAppDomain $existedAppPrefix = Get-SPAppSiteSubscriptionName if (!existedAppDomain || !existedAppPrefix) { if (!$existedAppDomain) { Set-SPAppDomain $appDomain -ea:Stop } Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} $User = $accountName $account = Get-SPManagedAccount -Identity $User -ea:Silently if(!$account) { $PWord = ConvertTo-SecureString –String $accountPassword –AsPlainText -Force $Credential = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $PWord $account = New-SPManagedAccount -Credential $Credential -ea:Stop } $appPoolSubSvc = Get-SPServiceApplicationPool -Identity SettingsServiceAppPool if (!$appPoolSubSvc) { $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account } $appPoolAppSvc = Get-SPServiceApplicationPool -Identity AppServiceAppPool if ($appPoolAppSvc!) { $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account } $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc Set-SPAppSiteSubscriptionName -Name $appPrefix -Confirm:$false -ea:Stop } 

I want to warn you that the last command is for some reason very resource-intensive and may require all the minimum SharePoint requirements for the physical components of the server (“hardware”). In my case, the command was not executed several times, because there was not enough free memory in the virtual machine. If you have previously reinstalled SharePoint, you will need to delete the existing SettingsServiceDB and AppServiceDB database files.

So, SharePoint is installed and configured for our applications. Now we need SharePoint to report that our web application will be trusted. This process is described in detail here .
In short, it is necessary

1. create a self-signed IIS certificate (this certificate is only suitable for the debug stage, full solutions will require a domain or commercial certificate)
2. unload pfx and cer files
3. upload the certificate to SharePoint and link it to our web application

At the last point I will stop and sign for more. Essentially, you need to run the following PowerShell script:

 $publicCertPath = "publicCertPath *.cer" $appId = "app Id Guid" $spurl ="SharePoint site url" $appPrincipalDisplayName = "your app pricipal name" $spweb = Get-SPWeb $spurl $realm = Get-SPAuthenticationRealm -ServiceContext $spweb.Site $certificate = Get-PfxCertificate $publicCertPath $fullAppIdentifier = $appId + '@' + $realm $principal = Get-SPAppPrincipal –NameIdentifier $fullAppIdentifier -Site $spweb if(!$principal) { $issuer = Get-SPTrustedSecurityTokenIssuer | where {$_.NameId -eq $fullAppIdentifier} if ($issuer) { Remove-SPTrustedSecurityTokenIssuer -Identity $issuer.Id -Confirm:$False -ea:Stop } New-SPTrustedSecurityTokenIssuer -Name $appPrincipalDisplayName -Certificate $certificate -RegisteredIssuerName $fullAppIdentifier -Confirm:$False -ea:Stop $principal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spweb -DisplayName $appPrincipalDisplayName } Set-SPAppPrincipalPermission -Site $spweb -AppPrincipal $principal -Scope Site -Right FullControl iisreset 

After executing this script, any remote application with the $ appId identifier will be able to access the SharePoint elements through a certificate with a private key (pfx).
It is worth remembering the app id. This is the ID of our Web application. It will be used later in the web.config of the Web application as IssuerId.

The final step is to create a SharePoint App application. This process is described in detail later in the article . When creating a project, the Wizard will offer to fill in a number of parameters: Issuer Id (app id generated by us), path to the pfx certificate, password to the certificate. The created Web application can be replaced with a solution that already exists in Visual Studio in the project properties. After the SharePoint project and the web application are connected to the web application, the following parameters are populated in the web.config file:

  <appSettings> <add key="IssuerId" value="your app id" /> <add key="ClientSigningCertificatePath" value="your pfx file path" /> <add key="ClientSigningCertificatePassword" value="pfx password" /> </appSettings> 

Also in the Web application project, useful classes SharePointContext.cs and TokenHelper.cs will appear. These classes provide quite a few possibilities for interacting with SharePoint.

This integration is complete. If you further start a SharePoint project App through debug - SharePoint will first request permissions for our App. After accepting permissions, after going through a special SharePoint page (appredirect.aspx), we will get to the root of our Web application. It is believed that the integration process is completed on this, however, as will be seen later, we will face many pitfalls.

In the following articles I will discuss in more detail how to organize interaction with SharePoint (search and read documents and other SharePoint elements), create app-parts, localize the App , create your RibbonTab, automate the installation of App & Solution and how to prepare for publishing on the SharePoint Store.