How to Host Multiple Cloud Business Apps on the Same Azure Web Site


This post is in response to a recent forum post titled “How to Publish Multiple SharePoint-enabled LightSwitch apps to a single Azure Website or Cloud Service?”  The title of this is pretty post pretty much says it all.  Publishing multiple CBA’s to the same Azure Web Site can be achieved with minor configuration changes to the site and by including the right settings in the publish wizard.  I have created a video demonstrating this.  Below are the highlights for those of you that don’t care to hear my melodious voice 🙂

 

Login to the Azure Management Portal, either create a new or navigate to an existing Web Site.  Go to the Configure tab scroll to the bottom and create “Applications” for all your CBAs.

 

Once you have entered the values, hit Save and you will be set with Applications.  Navigate to “Dashboard” and click “Download the publish profile”

 

Now open your CBA in Visual Studio.  The app is published as you would normally publish a provider-hosted CBA, with a few exceptions:

The application must use the IIS path of the publish wizard where you will import the publish settings file you exported in the previous step.

 

On the “Publish Settings” page add the application name.

 

On the “SharePoint Client ID” page, the URL needs to be completely changed to the full URL of the web application that was defined in the Azure Portal.

 

That is it for what is different.  Deploying the SharePoint app package isn’t any different than a “normal” CBA deployment. 

So the key takeaways are:

  • Create Application directories in the Azure Portal for each of your apps
  • Use the IIS path of the publish wizard instead of the Azure path
  • Update the appropriate URLs in the publish wizard to include the app name
Comments (25)

  1. adefwebserver says:

    Great job!

    So simple… once you explain it 🙂

  2. Yann Duran says:

    I wondered if the solution might involve "virtual applications" as you've outlined, but I neither had the time to explore it, nor the knowledge of how to implement it. There's a reason my blog is called "A Reluctant Web Developer".

    Thanks for the explanation Dave.

    However, as I've stated in that thread, we've had so much trouble with the whole provider-hosted scenario that we've had to start seeking alternatives to using SharePoint-enabled LightSwitch apps at all.

  3. Anonymous says:

    Dave, if we're using a custom domain (secured with a certificate) to point to the Azure website that we want to publish multiple LightSwitch apps to, when we publish an app to one of the virtual applications we've set up according to your description above, can we use the custom domain in the url taht we supply in "Where is your LightSwitch application hosted"? Or do we have to use the Azure website's "site url"?

    The reason I ask is because it's much easier to just publish with the same domain that the end-user will use, so if we decide to say move the virtual application to another Azure website, or even to a cloud service, we don't have to actually change any settings.

    An example:

    Azure website: mywebsite.azurewebsites.net

    Application: sitewwwrootmyapplication

    Custom domain: mydomain.com

    Can we use: mydomain.com/myapplication

    Or do we have to use: mywebsite.azurewebsites.net/myapplication

    Also, is it necessary for that setting to exactly match what you provide when generating the client id/secret? If so then any time we want to move it from say a testing site to a production site, for example, we'd need to generate a new setting client id/secret & publish a new version with those details.

    I hope all that makes sense.

  4. Yann Duran says:

    Umm, that was my question Dave. I'm not sure why it's saying "anonymous", because I was logged in when I posted it.

  5. Dave Kidder says:

    Hey Yann, I will need to think on this one for a bit, but I will get back to you soon.

  6. Yann Duran says:

    OK Dave, that's great – thanks!

  7. Dave Kidder says:

    Sorry this took a while Yann.  You should be able to use the custom domain.

    The "Enter the URL to the root…" entry in the publish wizard CAN indeed be different than what you entered in SharePoint, in fact this is the value that actually gets used after the publish (I actually mentioned this in the video).  Keep in mind though, that the URL that you put into the publish wizard MUST be in the domain that you entered in the "App Domain" entry in SharePoint (as this is not overwritten on publish (since this is in the SharePoint ID store)).  So you could use different production/staging applications on the same site, using the same ClientID/Secret, but if you want to use different sites for production/staging, you'll need to use different ClientID/Secret and change them at publish time.

  8. joshbooker says:

    Dave

    Thanks again for this

    Regarding the last sentence of your last comment above…(same clientid for two apps on single site)

    What about the redirect URL (sharepointlaunch.aspx)?

    Since that is unique and it's entered both on appregnew and pub wiz, don't you need different client ID and secret?

  9. joshbooker says:

    Dave,  Please disregard my post above.  I tried it and watched the vid in which you mention the redirect URL on appregnew being over-ridden by pub wiz.  I am able to use the same idsecret for two diff apps published to virtual directories of a single website.  

    One thing worth noting on this is that I believe you cannot use the same idsecret if the apps are to be installed on different sharepoint sites.  This is because appregnew.aspx is specific to the site you're generating from.  

    The solution is to always use Seller Dashboard to generate idsecret.  That way you can have a single ID for all apps on a single domain – AND deploy those apps to any number of SPO tenancies without changing the IDSecret.

  10. Yann Duran says:

    @josh – thanks for the offer of help in my forum post, I just haven't had time to get back to you. I just want to clarify your statement above. You're stated that if you use the Seller Dashboard (which I had tried in my many attempts to get apps installed to multiple SharePoint tenancies) that you can use a *single* id/secret combination for "all apps on a single domain". What do you actually mean by that? And are you saying that you've actually been able to compile *an* app with client id/secret generated in the Seller Dashboard, & then install those apps in SharePoint sites in completely different tenancies? As I said, I had tried that combination a while back, but had no success, but if it works now I'll be a very happy man. Well a relieved one anyway. Thanks!

    Btw, I don't use Skype anymore, only Lync (with a different email address than the one you have), so that's why you haven't seen me online for ages. I can't post that email address here, but if you'd still like to be in touch, you can email me & I'll try to add you to Lync.

  11. Dave Kidder says:

    @Josh, slight clarification on this point:

    "One thing worth noting on this is that I believe you cannot use the same idsecret if the apps are to be installed on different sharepoint sites.  This is because appregnew.aspx is specific to the site you're generating from."

    ClientID/Secret generated from appregnew.aspx are valid for any site within the *tenant*.  So if you get an id from:

    blah.sharepoint.com/DevSite1/_layouts/15/appregnew.aspx

    you can still deploy an app that uses this ID/Secret to:

    blah.sharepoint.com/AnotherSite

    but you couldn't deploy it to:

    <anyOtherTenant>.sharepoint.com

    @Yann, if you want to get an app deployed on multiple tenants, attaining the ID/Secret from the Seller Dashboard is the way to do this (I realize that you aren't having luck getting your apps deployed right now, but this is indeed the way to get ID/Secrets that can be used on multiple SharePoint tenants.

    Again you need to remember, though, that there is a 1-1 mapping between a ClientID & the website that you can host the middle-tier (i.e. the normal LightSwitch part of the publish process).  So it's possible to host two different SharePoint apps with the same ClientID/Secret if their middle tiers are deployed to:

    davesWebServer.com/App1

    davesWebServer.com/App2

    but it is NOT possible to do this with the same ClientID/Secret:

    davesWebServer.com/App1

    yannsWebServer.com/App1

    It's confusing since the term site and tenant is really overloaded here in dealing with the SharePoint side and the LightSwitch middle-tier (i.e. Server) deployment.  Tomorrow, I will try to make a diagram with what's possible and not possible to do regarding the combinations of these factors.

  12. Yann Duran says:

    Hi Dave,

    Thank you for the clarification!

    I'm just about to give it a go using the Seller Dashboard. I'll report back one way or the other.

  13. Yann Duran says:

    Hi Dave,

    My initial attempt was unfortunately not successful. Here's are the steps I followed (& I took screenshots every step of the way as well).

    1. In the Seller Dashboard, I enter "Yanns-Website" as the friendly name, "yannswebsite.azurewebsites.net" as the app domain, "https://yannswebsite.azurewebsites.net&quot; as the app redirect url, valid 3 years, worldwide.

    2. I click "Generate Client Id", & copy the resulting client id/secret to a safe place.

    3. Using a previously-created Azure website, in website's "Configure" tab, I add "/yannsapp" & "sitewwwrootyannsapp" in the "Virtual Applications" section, ticking the "Application" checkbox, & click "Save" at the bottom of the screen.

    4. I then download the publish profile for the website from the "Dashboard" tab. I decided to click the "Validate Connection" button, to see what would happen, & I got a "Could Not Complete an Operation With the Specified Provider (ERROR_)" error dialog box

    5. I then publish the app in Visual Studio 2013:

     a) I select "provider-hosted" as the host option

     b) I choose "IIS Server" as the "Where will the App's Services be Hosted" option (clicking on the "Import Settings" button to import the downloaded publish profile)

     c) I select "Publish Directly to the Server Now" as the "How do you Want to Create the Website" option

     d) I enter "yannswebsite/yannsapp" as the "Site/Application" in the "Specify the Settings" option, leaving the other values as they are

     e) I tick the box to "Remove Additional Files"

     f) I choose "Yes" for "Should LightSwitch Require a Secure Connection" option

     g) I verify that my data source (an Azure SQL database) is correct

     h) I enter "yannswebsite.azurewebsites.net/yannsapp" as the "Where is Your LightSwitch Application Hosted" option

     i) I enter the client id/secret that I generated for the app's "app domain" in the Seller Dashboard

     j) I click "Publish" on the "Summary" tab

     k) I then copy the resulting SharePoint ".app" file to the client's App Catalog

     k) I register the app (using "/appregnew.aspx"), with the client id/secret from the Seller Dashboard

     l) for good measure I also "lookup" the client id (in the "/appinv.aspx" page that I didn't even know existed until I watched your video

     m) I add the app to the client's SharePoint site (in this case it was an upgrade, as the app was already previously installed in that site)

     n) I click "Trust It"

     o) when the app has installed, I click on the resulting icon in the site's "Site Contents"

     p) boom! I get the exact same "You do not have permission to view this directory or page" err that I've always had

  14. Yann Duran says:

    The url that was invoked was "yannswebsite.azurewebsites.net/…/SharePointLaunch.aspx

    ?SPHostUrl=https%3A%2F%2Fclientstenant%2Esharepoint%2Ecom%2Fsites%2Fsitename

    &SPLanguage=en-US

    &SPClientTag=0

    &SPProductNumber=16%2E0%2E3208%2E1222

    &SPAppWebUrl=https%3A%2F%2Fclientstenant-someguid%2Esharepoint%2Ecom%2Fsites%2Fsitename%2Fyannsapp".

    If anyone can point out anything that I've done wrong I'd appreciate it. Or Dave if what I'm trying to do isn't covered by your clarification above, please let me know.

  15. joshbooker says:

    Yann

    You can skip(k) when you publish using id/secret from seller dashboard

    Appregnew in SharePoint is not needed if you are using seller dashboard.

    Also, in my experience, upgrade is not automatic

    I always upload app to catalog, remove deployed app from SharePoint site (site contents page) then add app again double checking version numbers before launch for good measure

    HTH,

    Josh

    Ps. I would think you of all people would prefer to be having this discussion in the forums, I know I would prefer that.

  16. joshbooker says:

    Ps also you need https:// in the pub wiz client I'd page

  17. Yann Duran says:

    Hi Josh,

    Thanks for looking over my steps, & for letting me know about "k" not being needed when using the Seller Dashboard.I did actually have"https" in the Publish Wizard, I just transcribed it without (I had to change a client's details into the fictitious example, & then had to rush out before I could proofread properly).

    I'll try your suggestion about removing the app & installing it instead of upgrading it.

    Your point about the forum is very valid. It often takes a while before a team member reads/replies to posts in the forum, & Dave has been kind enough to engage here, so in my haste I forgot where we were. If I get a chance, I'll transfer the contents of this thread to a new forum post.

    Thanks!

  18. joshbooker says:

    "It often takes a while before a team member reads/replies to posts in the forum"

    I hear you…. Increasingly so, in fact.

    "Dave has been kind enough to engage here"

    Kind indeed.  Dave is seemingly the only team member to remain somewhat active in forums over the past several months.  

    Perhaps the team is working on the elusive LS roadmap that's long been wanting.

    Thanks, Dave, for doing what you do.

  19. Dave Kidder says:

    Hey Yann, you might want to try getting a brand new ClientID/Secret from the dashboard, as the (k) step might have done something weird (as Josh pointed out, appregnew.aspx vs seller dashboard is a one-or-the-other thing (not both)).

    For some reason, sometimes the *first* time you hit the LightSwitch middle tier, you will get an Unauthorized, but if you go back to the SharePoint page and re-launch the app it works (don't know why this is).  Probably not what's going on in your case, but you could try if you haven't already.

    Michael has a good blog post on this.  I don't see anything else that is wrong with your steps, although.  Monday I can try going through the whole process to make sure I am not missing something.

  20. Dave Kidder says:

    Thanks for the kind words btw guys, happy I can help.

  21. joshbooker says:

    If getting a new idsecret from dashboard doesn't work then as Dave said…something 'weird' may be going on in SPO as a result of doing appregnew.aspx.  

    This may the kind of weirdness that has no fix (aside from a lengthy and painful trip through the O365 support request process)

    I would test deploying to another tenancy first. Then once I get success there, I would try again in this tenancy but before publishing try changing the ProductID GUID in AppManifest.xml of SharePoint project.  

    To do this open appmanifest.xml Code View and change a digit in ProductID GUID.

    This is only if the app works on other tenancies and not this one cuz SPO is 'weirded-out'.  

    This is also how you can install two of the same LS app on the same tenancy.  Like if you want to publish the same app but with diff database connections.  You can change the AppName and AppTitle there too if you want something in SharePoint other than the LS Project name.

  22. Yann Duran says:

    @davejosh. – Thank you both! I'm currently rebuilding my machine, so I'll try your suggestions as soon as it's done

    @dave – credit where credit's due, that's all our thanks are 🙂

  23. Yann Duran says:

    Umm, obviously, that was meant to be dave / josh

  24. Yann Duran says:

    Hi Guys,

    Just a quick update on where I got to with this (I still intend to update the forum thread as well too).

    Thanks to the combined information from both of you (Dave & Josh), using just the Seller Dashboard, & changing the product id in the SharePoint project's "AppManifest.xml" file, I have actually *finally* managed to get the provider-hosted scenario working. We've even been able to publish some of the existing auto-hosted apps as provider-hosted apps as well. I can't tell you how relived my client is that the problem is now (mostly – more on that in a minute) solved. So thank you both so much!

    I was also able to publish several different LightSwitch apps to a single Azure website, using Dave's video, so the client is also pretty happy with the progress made there as well. There is however a new problem, one that I'm hoping one of you will say "oh yeah, I've seen that, just do this…" 🙂

    In these apps, from a Web API controller, we read data from a SharePoint list (let's call it "Settings"), but what's happening is that when different clients run one of the apps (each on separate O365 tenants), they're all getting the *same* Settings values, even though they're supposed to be being read from their own individual SharePoint list.

    So it it possible to do what we're trying to do here? It seems like the website is caching the first values it gets asked for. The "Settings" list on each SharePoint site has the same name, & was created using the same GUID value (as some older code uses the GUID value to get the correct list). This problem is occurring for both apps that use the old code, as well as apps that use CSOM code.

  25. Yann Duran says:

    Sorry I forgot, we're also unable to use the custom domain. We can't enter it in the Seller Dashboard because it's a ".au" domain, & we can't just use the Azure Website name in the Seller Dashboard, & then use the custom domain's address in the link, even though a CNAME is set up to point to the website, because then it doesn't match what was entered in the Seller Dashboard.

    A bit of a catch 22 scenario.