I had a nice question today from my good friend Bala, who was working on some app stuff and talking to me about AppRegNew.aspx. We have a nice article on how to use this here: http://msdn.microsoft.com/en-us/library/jj860570.aspx, which is talking about packaging up your applications. The minor disconnect (mostly on my part) was the use case for it, given that with the Office Developer Tools Preview 2 bits for Visual Studio 2012 you can deploy and debug your application without having to use appregnew.aspx. Fortunately, this is where my other good friends Siew and Yaqi came to the rescue.
As they have pointed out, you don't have to worry about messing with the clientId in the web.config of a provider hosted app or an app's manifest file while you are developing it. Visual Studio takes care of creating a clientId and registering it with SharePoint when you hit the F5 run button. However, once you are ready to deploy to a different site collection then where you are doing your development, this is when you need to follow the steps outlined in the article above to use appregnew.aspx to get a new clientId. NOTE: If you are creating an app for the SharePoint Store then you would get your clientId and clientSecret from there.
Once you have the Id and optionally secret, you need to publish your application as described in the article and plug in the numbers that were generated for you by appregnew or the store into the web.config file of your provider hosted app. The publishing process will create a .app file along with a deployment batch file. However what you can do is just take the .app file and upload it to an app catalog, and then you can install it into any site collection in the farm - as long as the catalog and sites are in the same farm (or tenant if you're in o365) where you created the Id with appregnew. In fact you can upload it into any app catalog in the farm and install it in any site collection in any web app at that point - again, as long as they are all in the same farm where you used appregnew.
Hopefully this helps clarify the use case if you had some confusion on this. Thanks again to Yaqi and Siew for helping me with the details here.
It clarifies and doesn't clarify
What is the AppRegNew.aspx actually for besides creating the "App Secret" (as the AppId is just a GUID)? Does it actually do anything in the background (Subscription Settings Service? App Management Service?) or is it actually just a "generator" for the AppId + App Secret?
Figured it out on my own: It actually creates a new entry in the App Management Database inside the AppPrincipals table. That means each time I hit "Create" on that page a new App Principal is created.
Question is how I would remove these App Principals? Say I didn't write down my App Secret and I want to create a new one - of course I would want to delete the vacant App Principal. How would I do that?
@moontear - You can delete these principals using the 'Remove-MsolServicePrincipal' powershell cmdlet. See here for more details :
Jomit, The Get-MsolServicePrincipal cmdlet is for Office 365. Are you sure this is meant for managing App Principals?
In any case: I can't use these cmdlets on premise, hence don't have a clean way to remove these vacant App Principals.
_layouts/15/appprincipals.aspx - If I'm not mistaken I think that URL will let you view and delete these principals
You can use the Register-SPAppPrincipal command in PowerShell to force register a ClientId on other deployment environments of the DTAP street.
Look at the explanation here: