I am not able to get this to work
call "%MSDeployPath%msdeploy" -verb:sync -source:runCommand='backup.bat param1' -dest:auto,computername=10.xx.xx.xx,username=xxx,password=yyy
It gives me:
Warning: 'backup.bat' is not recognized as an internal or external command, operable program or batch file.
Warning: The process 'C:\Windows\system32\cmd.exe' (command line '') exited with code '0x1'. Total changes: 1 (0 added, 0 deleted, 1 updated, 0 parameters changed, 0 bytes copied)
If I remove the param1 and hardcode it inside the .bat, it works, so there's no problem with the bat file, in case you wonder.
I tried to specify the full path to .bat and it still doesn't work:
call "%MSDeployPath%msdeploy" -verb:sync -source:runCommand='c:\backup.bat param1' -dest:auto,computername=10.xx.xx.xx,username=xxx,password=yyy
In this case, it looks like it interprets the path as a remote path, it expects backup.bat to be on the server. This was confirmed to me after I moved backup.bat on the server, it worked
WHY does it have to be so HARD???
Edit You are right, the documentation states that cmd/bat files will be streamed to the destination.
It seems to me that it's simply a limitation of the feature that it can't accept arguments. It shouldn't be too difficult to create a modified version of the batch file at deploy-time with the settings hardcoded.
Something like:
Update Having browsed the reflected source (ahem) of msdeploy, I can confirm that it's simply the way it's current designed. It determines whether to upload the file based on whether the entire path represents a file. Since adding arguments will prevent it resolving the path to a file, it doesn't upload anything.