Open ikkhatri opened 7 months ago
Hello i encounter the same issue, anyone found a solution to this?
Found a temporary workaround, will create a pull request now
@ikkhatri my solution works fine, tried it yet? any idea on how to improve it?
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 :)
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!
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
Were you still experiencing this issue with the 1.4.4 version of the IntuneWin32App module?
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.
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.
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
[error]PowerShell exited with code '1'.
Finishing: New-Win32App