3

I have created a provider hosted app which is primarily used for testing several aspects of a SharePoint environment. The app will be installed in different customer environments, so on different farms and with a different target for the IIS / ASP.NET MVC part of the app.

Now upon packaging the SharePoint app package, the URL of the app is hardcoded in the package (see http://blogs.msdn.com/b/kaevans/archive/2013/08/20/alm-for-sharepoint-apps-understanding-provider-hosted-app-publishing.aspx). This means that the app package is environment specific and cannot be reused. Any new environment would mean a new app package and thus going into Visual Studio and creating the package, which will be annoying after two times and not something you want to bother a developer with.

Another option would be unpacking the zip, editing the file and doing a find/replace. Not sure about that either, seems error prone and I'm not sure whether editing that single file is enough (read the above mentioned post for more info).

So I was wondering whether anyone has tackled this topic and if so: how? I thought about writing a Powershell script which would:

a) ask the user for input (target URL, app catalog)

b) unzip the app package

c) replace the values automatically

d) re-zip the app package

e) upload the app to SharePoint app catalog

I'd like to have your input to explore further options.

0

Assuming your add-in doesn't include an appweb/appweb borne feature activations then the app package is little more than UI sugar, as the app can be launched using a javascript widget that navigates to the AppRedirect.aspx page using the apps ClientId and SPHostUrl querystring parameters.

This is what the LaunchApp(appInstanceId, clientId, launchUrl, dialogOptions, isTenantApp) function in Core.js does;

  • appInstanceId - can be null, if clientId supplied
  • clientId - can be null, if appInstanceId supplied
  • launchUrl
  • dialogOptions - if being called via custom action
  • isTenantApp - true/false is a tenant scoped app

The manifest file in the App package also contains the apps ClientId, which you'd need to consider unless you where planning to reuse the same ClientId/Secret across environments.

If you're on-prem I believe there are Powershell commands which you could use to register an app principal (the same as what AppRegNew.aspx does)

Also the PnP group offer some build extensions and techniques which might be useful, such as build tasks for creating app packages and remote operations for registering app principals.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.