MsDeploy remoting executing manifest twice

Question

I have:

1. Created a manifest for msdeploy to:
   Stop, Uninstall, Copy over, Install, and Start a Windows service.
2. Created a package from the manifest

Answer 1

There is not enough information in the question to really reproduce the problem to give a specific answer... but there are several things to check/change/try to make this work:

• runCommand needs specific privileges
• waitInterval="240000" and waitAttempt="1" (double quotes instead of single quotes)
• permissions for the deployment service / deployment agent regarding directories etc. on the target machine
• use tempAgent feature
• work through the troubleshooting section esp. the logs and try the -whatif and -verbose options

EDIT - after the addition of -verboseoutput:

I see these possibilities:

• Time
  Both machines have a difference in time (either one of them is just a bit off or some timezone issue...)
• Filesystem
  If one of the filesystems is FAT this could lead to problems (timestamp resolution...)

EDIT 2 - as per comments:

In my last EDIT I wrote about timestamp because my suspicion is that something goes wrong when these are compared... that can be for example differring clocks between both machines (even a difference of 30 sec can have an impact) and/or some timezone issues...

I wrote about filesystem esp. FAT since the timestamp resolution of FAT is someabout 2 seconds while NTFS has much higher resolution, again this could have an impact when comparing timestamps...

From what you describe I would suggest the following workarounds:

• use preSync and postSync for the Service handling parts (i.e. preSync for stop + uninstall and postSync for install + start) and do only the pure sync in the manifest or commandline
  OR
• use a script for the runCommand parts

EDIT 3 - as per comment from Merlyn Morgan-Graham the result for future reference:

When using the runCommand provider, use batch files. For some reason this made it stop running two passes.

The problem with this solution is that one can't specify the installation directory of the service via a SetParameters.xml file (same for dontUseCommandExe / preSync / postSync regarding SetParameters.xml).

EDIT 4 - as per comment from Merlyn Morgan-Graham:

The timeout params apply to whether to kill that specific command, not to the closing of the Windows Service itself... in this case it seems that the Windows Service takes rather long to stop and thus only the runCommands get executed without the copy/sync and a new try for the whole run is initiated...

Answer 2

I had the same problem, but I don't make package.zip file. I perform synchronization directly in one step. The preSync/postSync solution helped me a lot and there is no need to use manifest files. You can try the following command in your case:

"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy"  
-verb:sync 
-preSync:runCommand="net stop TestSv && C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe /u
       C:\msdeploy\TestSvc\TestSvc\bin\Debug\TestSvc.exe",waitInterval=240000,waitAttempts=1 
-source:dirPath="C:\msdeploy\TestSvc\TestSvc\bin\Debug"
-dest:auto,computername=<computerNameHere>
-postSync:runCommand="C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe
    C:\msdeploy\TestSvc\TestSvc\bin\Debug\TestSvc.exe && net start TestSvc",waitInterval=240000,waitAttempts=1

"-verb:sync" parameter means you synchronize data between a source and a destination. In your case your case, first time you perform synchronization between the "C:\msdeploy\TestSvc\TestSvc\bin\Debug" folder and the "package.zip". Plus, you are using manifest file, so when you perform second synchronization between the "package.zip" and the destination "computername", msbuild uses previously provided manifest twice for the destination and for the source, so each manifest operation runs twice. I used the && trick to perform several commands in one command line. Also, in my case, I had to add timeout operation to be sure the service were completely stopped ("ping -n 30 127.0.0.1 > nul").