未被TeamCity PowerShell Runner识别的PowerShell社区扩展

当TeamCity Powershell运行器运行我的.ps1文件时，它无法识别Write-Zip命令，它是Powershell社区扩展的一部分。未被TeamCity PowerShell Runner识别的PowerShell社区扩展

我可以在构建服务器上手动运行相同的命令，它工作得很好。我已经验证了TeamCity和我都在运行powershell.exe的x64版本，并且两者都以同一用户身份运行。

[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]

我认为这可能与PowerShell运行于不同的环境有关，但我还没有完全理解这一点。

我在剧本正在像这样运行的TeamCity构建日志中发现：

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

注意，PowerShell是正在运行C：\ WINDOWS \ sysnative \ cmd.exe的

然而，在构建服务器上，我没有看到此目录或cmd.exe版本，并且如果我尝试从PowerShell或命令提示符运行相同的命令，则表示它找不到C：\ Windows \ sysnative \ cmd .exe

有谁知道TeamCity a通常运行Powershell？

更新

我试图运行使用命令行亚军我的PowerShell脚本，然后调用使用-file命令一样的TeamCity会做powershell.exe。

我有任务管理器运行，看到cmd.exe进程它跑为C：\ WINDOWS \ Syswow64资料\ cmd.exe的

我得到了确切的相同的错误上面印，写-Zip是无法识别。但是，如果我手动在... \ SysWOW64 \ cmd.exe中运行相同的命令，它将起作用。

再次，无论是运行在同一台机器上相同的用户，根据任务管理器

来源

2013-07-17 Michael

基思的回答让我走上了正确的道路。

我能够来解决这个问题，从Ç移动Pscx模块安装：\ Program Files文件（x86）的...到C：\ WINDOWS \ SYSTEM32 \ WindowPowerShell \ 1.0 \模块

不知道为什么默认情况下，社区扩展未在所有其他模块的Module目录中安装。但由于某种原因，当TeamCity位于Program Files（x86）目录中时，它无法加载该模块。

我从TeamCity运行64位版本的PowerShell，在这种情况下，它将无法加载32位（x86）模块，但我也运行64位版本的当我手动做它，然后它的工作。

所以我仍然有点困惑，为什么TeamCity无法看到模块，但将其移动到正确的PowerShell安装中的Modules目录解决了问题。

来源

2013-07-17 17:46:31 Michael

仅供参考PSCX模块由于处于PSModulePath系统环境目录中而被找到。我想知道TeamCity是否没有看到PSModulePath？你刚安装PSCX吗？ –

安装了最新的PSCX后，我遇到了同样的问题，它破坏了我现有的TC设置。我通过确保机器PSModulePath是最新版本（包括pscx的模块路径）并重新启动机器以使TC看到新值（可能只是重新启动TC足够 - 不确定）来修复它。 – Marcus

你导入PSCX模块在你的脚本？完成此操作后，PowerShell v3会缓存模块信息，因此无需再次导入它。但是，如果TeamCity运行64位控制台，并且通常运行32位控制台，则64位控制台在命令缓存中不会有PSCX命令。无论如何，让你的脚本明确需要它所依赖的模块是一个好习惯。

#requires -Modules Pscx

来源

2013-07-17 16:43:06

不知道这是否有助于任何人，但我已经打开了cmder，团队城市的代理在同一用户下运行。出于某种原因，通过打开cmder可以以某种方式锁定powershell。我无法解释，但关闭cmder解决了这个问题。

来源

2016-06-15 18:45:32 TheWebGuy

未被TeamCity PowerShell Runner识别的PowerShell社区扩展

回答

相关问题