4
votes

When the TeamCity Powershell runner runs my .ps1 file it doesn't recognize the Write-Zip command, which is part of the Powershell community extensions.

I can run the same command manually on the build server and it works just fine. I've verified that both TeamCity and I are running the x64 version of powershell.exe and both are running as the same user.

[17:21:22][Step 5/5] Packaging WWW.zip
[17:21:45][Step 5/5] Write-Zip : The term 'Write-Zip' is not recognized as the name of a cmdlet, 
[17:21:45][Step 5/5] function, script file, or operable program. Check the spelling of the name, or 
[17:21:45][Step 5/5] if a path was included, verify that the path is correct and try again.
[17:21:45][Step 5/5] At 
[17:21:45][Step 5/5] C:\TeamCity\buildAgent\work\e19b1309c030c7e2\Build\PowerShell\Package.ps1:20 
[17:21:45][Step 5/5] char:1
[17:21:45][Step 5/5] + Write-Zip -InputObject $items -OutputPath .\WWW.zip
[17:21:45][Step 5/5] + ~~~~~~~~~
[17:21:45][Step 5/5]     + CategoryInfo          : ObjectNotFound: (Write-Zip:String) [], CommandNo 
[17:21:45][Step 5/5]    tFoundException
[17:21:45][Step 5/5]     + FullyQualifiedErrorId : CommandNotFoundException
[17:21:45][Step 5/5] 

I think it may be related to powershell being run from a different environment but I don't fully understand this yet.

I found in the TeamCity build logs that the script is being run like this:

 C:\Windows\sysnative\cmd.exe /c C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -ExecutionPolicy ByPass -File C:\TeamCity\buildAgent\work\e19b1309c030c7e2\Build\PowerShell\Package.ps1 -WorkingDirectory C:\TeamCity\buildAgent\work\e19b1309c030c7e

Notice that powershell is being run by C:\Windows\sysnative\cmd.exe

However, on the build server, I don't see this directory or version of cmd.exe, and if I try to run the same command from PowerShell or Command Prompt, it says that it can't find C:\Windows\sysnative\cmd.exe

Does anyone know how TeamCity actually runs Powershell?

Update

I tried running my powershell script using the Command Line Runner and then calling powershell.exe with the -File command just like TeamCity would do.

I had TaskManager running and saw the cmd.exe process it ran was C:\Windows\SysWOW64\cmd.exe

I got the exact same error as printed above, Write-Zip is not recognized. However, if I run the same command in ...\SysWOW64\cmd.exe manually, it works.

Once again, both running as the same user on the same machine, according to TaskManager

3

3 Answers

1
votes

Do you import the PSCX module in your script? PowerShell v3 will cache the module info after you have done this once so you don't need to import it again. However if TeamCity is running the 64-bit console and you normally run the 32-bit console, then the 64-bit console wouldn't have PSCX commands in the command cache. Anyway, it is a good practice to have your scripts explicitly require the modules it depends upon e.g.

#requires -Modules Pscx
1
votes

Keith's answer started me down the right path.

I was able to fix the problem by moving the Pscx module installation from C:\Program Files (x86)... to C:\Windows\System32\WindowPowerShell\v1.0\Modules

Not sure why the community extensions don't get installed in the Modules directory with all the other modules by default. But for some reason TeamCity couldn't load the module when it was in the Program Files (x86) directory.

I was running the 64 bit version of powershell from TeamCity, in which case it would make sense that it wouldn't be able to load the 32 bit (x86) module, but I was also running the 64 bit version of powershell when I did it manually and it worked then.

So I'm still a little confused as to why TeamCity couldn't see the module, but moving it to the Modules directory in the correct powershell installation fixed the issue.

0
votes

Don't know if this helps anyone, but I had cmder open and team city's agent was running under the same user. For some reason by having cmder open it kept a lock on powershell somehow. I can't explaining but closing cmder resolved the issue.