Specify value for ~remoteAppUrl in an Office add-in manifest - outlook

Question

I'm writing an add-in for Outlook using the new framework. The manifest in the project template uses ~remoteAppUrl to represent the location of the web files. It works great during development, but to publish to the Office Store I need the production URL there. If I save the production URL to the manifest, the production server gets used during debugging, and so local changes don't show up.
The documentation mentions Visual Studio filling in this value during debugging:
Next, Visual Studio does the following:
1. Modifies the SourceLocation element of the XML manifest file by replacing the ~remoteAppUrl token with the fully qualified address of the start page (for example, http://localhost/MyAgave.html).
Is there a built-in way to have Visual Studio fill in the production URL at the appropriate time (before/during Office Store submittal), and not break debugging?

Answer 1

Yes, there is a built-in way to have Visual Studio replace the ~remoteAppUrl symbolic reference token by the target URL of your choice.
From Visual Studio, access the "Publish..." option of the add-in
project, then click on the "Package the add-in" button
You can then enter the URL in the modal dialog that pops up
A build is then triggered that will inject the URL in the produced Manifest XML file
A Windows Explorer window will conveniently open to show the
produced file.
The following ways are not built-in but may be useful as well.
If you want this in an automated build, you need to specify values for the build parameters IsPackaging (True) and RemoteAppUrl.
If you want this in the standard Visual Studio Build, given that Visual Studio does not provide an easy way to specify Build parameters (see How to emulate /p msbuild parameter in Visual Studio build?) you will need to edit your project file to set the values of the same build parameters.
For instance like this:
...
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
...
<IsPackaging>True</IsPackaging>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<RemoteAppUrl>https://localhost:44300</RemoteAppUrl>
</PropertyGroup>
...
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<RemoteAppUrl>https://your.own.url</RemoteAppUrl>
</PropertyGroup>
...

Answer 2

Edit:
Visual Studio will not fill in the production URL, however you can copy your current manifest and replace the ~remoteAppUrl with your appropriate host manually, thus giving you a production and debug version of your add-in.
Original for posterity
~remoteAppUrl is a placeholder for wherever your files are hosted. For instance, if you have uploaded your add-in to an Azure Web App, your remote app url would be something along the lines of myWebApp.azurewebsites.net

Answer 3

I would like to bring the light on where the value comes from to replace the ~remoteAppUrl parameter. Add-in .csproj file contains the reference to the WebApp project:
<ItemGroup>
<ProjectReference Include="..\OutlookWebAddIn1Web\OutlookWebAddIn1Web.csproj">
<Project>{57AC33A8-A364-4084-B41F-319C5DBB9FB4}</Project>
<Name>OutlookWebAddIn1Web</Name>
<Private>True</Private>
<RoleType>Web</RoleType>
<OutputItemType>SharePointWebProjectOutput</OutputItemType>
<RoleName>OutlookWebAddIn1Web</RoleName>
<ReferenceOutputAssembly>False</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
I think it takes the URL from the WebApp .csproj file: