Closed skmcavoy closed 8 months ago
I am not sure if there was not some change in the folder structure of the vsix duringBC versions. The structure I am using in the script is this:
It means the alc.exe is in the bin folder itself (and another copy is in the win32 subfolder). I will check the structure on BCv24...
released in v2.7.0.
Thanks for reporting!
Unfortunately this still fails with 2.7.0 on Line 50. The Split-Path operation fails due to a null path:
Removing C:\Users\BUILDA\~1\AppData\Local\Temp\alc Locating the vsix path in c:\bcartifacts.cache\sandbox\24.0.16336.0\platform Extracting ALLanguage.vsix into C:\Users\BUILDA~1\AppData\Local\Temp\alc using 7zip
[debug]Leaving C:\agent_work_tasks\CompileBCApps_6d011eb8-627b-48f8-8fef-506f72da1626\4.1.0\compileapptask.ps1.
[debug]Caught exception from task script.
[debug]Error record:
[debug]Get-ALCompilerFromArtifact : Cannot bind argument to parameter 'Path' because it is null.
[debug]At C:\Users\BuildAgent\Documents\WindowsPowerShell\Modules\NVRAppDevOps\2.7.0\Compile-ALProjectTree.ps1:119 char:32
[debug]+ ... $alcPath = Get-ALCompilerFromArtifact -artifactUrl $artifactUrl -Tar ...
[debug]+
~~~~~~~~~~~~~[debug] + CategoryInfo : InvalidData: (:) [Get-ALCompilerFromArtifact], ParameterBindingValidationException
[debug] + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Get-ALCompilerFromArtifact
[debug]
[debug]Script stack trace:
[debug]at Get-ALCompilerFromArtifact, C:\Users\BuildAgent\Documents\WindowsPowerShell\Modules\NVRAppDevOps\2.7.0\Get-ALCompilerFromArtifact.ps1: line 50
[debug]at Compile-ALProjectTree, C:\Users\BuildAgent\Documents\WindowsPowerShell\Modules\NVRAppDevOps\2.7.0\Compile-ALProjectTree.ps1: line 119
[debug]at
, C:\agent_work_tasks\CompileBCApps_6d011eb8-627b-48f8-8fef-506f72da1626\4.1.0\compileapptask.ps1: line 72 [debug]at
, : line 1 [debug]at
, : line 22 [debug]at
, : line 18 [debug]at
, : line 1 [debug]Exception:
[debug]System.Management.Automation.ParameterBindingValidationException: Cannot bind argument to parameter 'Path' because it is null.
[debug] at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
[debug] at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
[debug] at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
[debug] at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
[debug] at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
[debug] at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
[debug] at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
[debug] at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
[debug] at System.Management.Automation.CommandProcessorBase.Complete()
[error]Cannot bind argument to parameter 'Path' because it is null.
[debug]Processed: ##vso[task.logissue type=error]Cannot bind argument to parameter 'Path' because it is null.
[debug]Processed: ##vso[task.complete result=Failed]
The line in question: $ALCPath = (Split-Path (Get-ChildItem -Path $TargetPath -Filter alc.exe -Recurse | Where-Object { $_.FullName -notlike 'win32' }).FullName)
Published in v2.7.1
Using BC24.0.16336.0
The following error occurs when trying to compile with artifact:
Looking at the source for Get-ALCompilerFromArtifact, it looks like it is purposely filtering away the win32 binary for alc.exe, resulting in no alc.exe being found in the search of the extracted vsix. Should the -notlike "*win32*" be a -like?
Ref: https://github.com/kine/NVRAppDevOps/blob/7d4173347d238d26064aa3ad206a2130f9c1c64b/NVRAppDevOps/Get-ALCompilerFromArtifact.ps1#L50C1-L50C144