New-Win32.ps1 Script failure

[ikkhatri]

Great work on the amazing solution.
Thought I would configure it and have a go. Setup was a breeze.
There seems to be an issue in the very last stage (publish) where it fails to run the New-Win32.ps1.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
at Microsoft.Management.Service.IntuneWinAppUtil.LogUtil.PrintProgress(AppContext context)
at Microsoft.Management.Service.IntuneWinAppUtil.PackageUtil.CreatePackage(String folder, String setupFile, String outputFolder, String catalogFolder)
at Microsoft.Management.Service.IntuneWinAppUtil.Program.Main(String[] args)
WARNING: Unable to detect expected 'Deploy-Application.exe.intunewin' file after IntuneWinAppUtil.exe invocation
Creating default requirement rule
Creating additional custom requirement rules
Creating detection rules
Constructing an icon object
Creating Win32 application
C:\ADOAgent_work\1\s\Scripts\New-Win32App.ps1 : Cannot validate argument on parameter 'FilePath'. Cannot bind
argument to parameter 'Path' because it is an empty string.
At C:\ADOAgent_work_temp\21af28b3-f0b6-4c6d-b7b4-db3447f4c6d3.ps1:4 char:1

• . 'C:\ADOAgent_work\1\s\Scripts\New-Win32App.ps1' -TenantID f1xxxx ...

•   + CategoryInfo          : InvalidData: (:) [New-Win32App.ps1], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,New-Win32App.ps1
  
  

##[error]PowerShell exited with code '1'.
Finishing: New-Win32App

[Jan-BaptistVandeuren]

Hello i encounter the same issue, anyone found a solution to this?

[Jan-BaptistVandeuren]

Found a temporary workaround, will create a pull request now

[Jan-BaptistVandeuren]

@ikkhatri my solution works fine, tried it yet? any idea on how to improve it?

[NickolajA]

I guess this is related to the latest issues with the changes Microsoft made to a specific version of the wrapper-utility that didn't like the output getting redirected (I was trying to hide this in the code of the New-IntuneWin32AppPackage function). I'm about to release a new version of the IntuneWin32App module, but family stuff and moving to a new house has gotten in the way. It should be just around the corner now though, as we're finally settling in :)

[Jan-BaptistVandeuren]

I guess this is related to the latest issues with the changes Microsoft made to a specific version of the wrapper-utility that didn't like the output getting redirected (I was trying to hide this in the code of the New-IntuneWin32AppPackage function). I'm about to release a new version of the IntuneWin32App module, but family stuff and moving to a new house has gotten in the way. It should be just around the corner now though, as we're finally settling in :)

Hope everything is going all right with your moving and family stuf.
My workaround "works" but as i am moving closer to releasing a newer version of what we do with pipelines and intune, i would be interested with your solution.
No rush at this point just pure curiousness, but only if you have the time for it of course!

[obuolinis]

My fix for this issue was to make sure absolute paths are passed to New-IntuneWin32AppPackage
$IntuneAppPackage = New-IntuneWin32AppPackage -SourceFolder (Resolve-Path $SourceFolder).Path -SetupFile $AppData.PackageInformation.SetupFile -OutputFolder (Resolve-Path $OutputFolder).Path

[NickolajA]

Were you still experiencing this issue with the 1.4.4 version of the IntuneWin32App module?

[obuolinis]

Yes that's the version I've done my tests with.

Disregard my above comment, I found where my problem was.
I realized the paths that get passed to New-IntuneWin32AppPackage are generated by Prepare-AppPackageFolder.ps1 and they are based on $AppsPublishRootPath variable value.

IntuneAppFactory/Scripts/Prepare-AppPackageFolder.ps1

Line 31 in 510a454

$AppsPublishRootPath = Join-Path -Path $env:PIPELINE_WORKSPACE -ChildPath "Publish"

Now, as part of adapting IntuneAppFactory for Github Actions I had to change all Azure Devops-specific environment variables and thus $env:PIPELINE_WORKSPACE was changed to $env:GITHUB_WORKSPACE. Before uploading and testing anything on Github I used Windows Sandbox to test things - there for simplicity I set $env:GITHUB_WORKSPACE to ".", and that's where my "bug" was born.
On a Github Windows runner GITHUB_WORKSPACE is actually set to an absolute path so a call to New-IntuneWin32AppPackage works correctly.

I'm sorry for confusion.