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
Anonymous
July 28, 2014
Great job! So simple... once you explain it :)Anonymous
July 28, 2014
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.Anonymous
August 08, 2014
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.Anonymous
August 08, 2014
Umm, that was my question Dave. I'm not sure why it's saying "anonymous", because I was logged in when I posted it.Anonymous
August 09, 2014
Hey Yann, I will need to think on this one for a bit, but I will get back to you soon.Anonymous
August 09, 2014
OK Dave, that's great - thanks!Anonymous
August 20, 2014
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.Anonymous
September 02, 2014
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?Anonymous
September 02, 2014
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.Anonymous
September 03, 2014
@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.Anonymous
September 03, 2014
@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.Anonymous
September 03, 2014
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.Anonymous
September 03, 2014
The comment has been removedAnonymous
September 03, 2014
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.Anonymous
September 03, 2014
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.Anonymous
September 03, 2014
Ps also you need https:// in the pub wiz client I'd pageAnonymous
September 04, 2014
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!Anonymous
September 04, 2014
"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.Anonymous
September 04, 2014
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.Anonymous
September 04, 2014
Thanks for the kind words btw guys, happy I can help.Anonymous
September 04, 2014
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.Anonymous
September 05, 2014
@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 :-)Anonymous
September 05, 2014
Umm, obviously, that was meant to be dave / joshAnonymous
September 15, 2014
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.Anonymous
September 15, 2014
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.