I looked into how the MSBuild tasks created by Microsoft deals with packaging an SharePoint App, and if they provide a way to do what you want.
To build the app package with msbuild, you can use this command:
msbuild /t:Package SPTimer.csproj /p:Configuration=Release /p:Platform="A
ny CPU" /p:OutputPath="<outputdir>\SPTimer"
Where you change SPTimer to be the name of your SharePoint App project, the command needs to be run from the directory of the SharePoint App project. In the outputdir a new folder named SPTimerapp.publish will be created with the content of the publishing process, both the published web project and an app package.
Unfortunately the msbuild tasks for packaging SharePoint Apps are not designed to take the ClientId and ClientSecret as input parameters, why do you have that requirement anyway the values should be static after the App is registered?
There is a work around, but it gets a little complicated, let me try to explain it. (Note I tested this on Visual Studio 2015, so it could in theory be different on VS2012, but I doubt it).
When you run the msbulid command outlined above, the msbuild targets defined the following two files are used:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SharePointTools
If you read, the .Apps.targets file you will find a MSBuild task named GetWebProjectSettings this task is implemented in Microsoft.VisualStudio.SharePoint.Tasks.dll. But from reading the msbuild file we can see that it outputs two properties WebProjectClientId and WebProjectClientSecret. The WebProjectClientId are later in the MSBuild process used in CreateAppPackage target, this target creates the AppManifest.xml for your app package and sets the ClientId equal to the WebProjectClientId.
From this knowledge you have two options,
- Create your own Apps.target file, and change the behavior of how the ClientID and ClientSecret are found
- Investigate how GetWebProjectSettings finds the ClientID and ClientSecret and change that.
I will not explain option 1 as that should be straight forward if you know MSBuild, you could simply change the two properties into being input parameters and provide them when running the msbuild command.
Option 2 requires us to figure out how the GetWebProjectSettings msbuild target is implemented. I opened Microsoft.VisualStudio.SharePoint.Tasks.dll in a .net refector to take a look at it. To get values for WebProjectClientId and WebProjectClientSecret the task opens the publishingprofilename.pubxml file from your web project and reads the values from the part of the xml that looks like this.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Description>Value for ClientId here.</Description>
<Description>Value for ClientSecret here.</Description>
The values that are used are the DefaultValue of the two MsDeployDeclareParameters sections. So if you want to go with option two, you could have a prebuild event where you update the value of those two xml nodes.
Hope this provide some idea on how to accomplish your goal, but I do think you should reconsider if you need it :)