search

MSEndpointMgr / IntuneAppFactory

Intune App Factory automates Win32 application packaging in Intune.
https://msendpointmgr.com/intune-app-factory
MIT License
40 stars 12 forks source link

New-Win32.ps1 Script failure #17

Open ikkhatri opened 10 months ago

ikkhatri commented 10 months ago

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

Jan-BaptistVandeuren commented 9 months ago

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

Jan-BaptistVandeuren commented 9 months ago

Found a temporary workaround, will create a pull request now

Jan-BaptistVandeuren commented 9 months ago

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

NickolajA commented 8 months ago

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 commented 6 months ago

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 commented 3 months ago

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 commented 3 months ago

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

obuolinis commented 3 months ago

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.

https://github.com/MSEndpointMgr/IntuneAppFactory/blob/510a4544ec263c6584748b09ffe3af625665521e/Scripts/Prepare-AppPackageFolder.ps1#L31

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.