MSIX Packaging Tool Failures: File not found issues (A workaround)

%3CLINGO-SUB%20id%3D%22lingo-sub-307073%22%20slang%3D%22en-US%22%3EMSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-307073%22%20slang%3D%22en-US%22%3E%3CP%3EIn%20packaging%20a%20lot%20of%20apps%2C%20I%20find%20that%20the%20Packaging%20tool%20fails%20quite%20often%20when%20saving%20the%20package.%26nbsp%3B%20In%20looking%20into%20the%20Log%20file%2C%20these%20errors%20are%20usually%20background%20system%20created%20files.%26nbsp%3B%20Like%20C%3A%5CWindows%5CSystem32%5Cconfig%5CSYSTEM.LOG1%20or%20LOG2.%26nbsp%3B%20Or%20those%20stupid%20wbem%20files.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAdding%20exclusions%20doesn't%20seem%20to%20help.%26nbsp%3B%20I%20even%20add%20them%20in%20the%20form%20shown%2C%20or%20in%20%5C%5C%3F%5CC%3A%5CWindows...%20form%20(as%20the%20log%20file%20hints%20at).%26nbsp%3B%20Still%20doesn't%20help.%26nbsp%3B%20Even%20though%20the%20files%20are%20in%20the%20exclusion%20list%2C%20they%20don't%20get%20excluded.%20%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EOne%20possible%20cause%20of%20this%20is%20hinted%20at%20by%20the%20workaround%20that%20I%20am%20using.%26nbsp%3B%20Rather%20than%20save%20the%20package%20off%20and%20have%20it%20fail%2C%20I%20find%20I%20must%20continue%20into%20the%20package%20editor.%26nbsp%3B%20From%20there%20I%20can%20manually%20look%20for%20potentially%20offending%20files%20and%20right-click%20delete%20them.%26nbsp%3B%20Then%20I%20can%20save%20the%20package%20off%20cleanly.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESo%20what's%20the%20hint%20about%20the%20possible%20cause%3F%26nbsp%3B%20Well%20when%20you%20add%20an%20exclusion%20(on%20an%20x64%20OS)%20to%20C%3A%5CWindows%5CSystem32%5Cconfig%5CSYSTEM.LOG1%2C%20this%20exclusion%20is%20mapped%20to%20and%20saved%20as%20%22%5B%7BAppVPackageRoot%7D%5D%5Cconfig%5CSYSTEM.LOG1%22%26nbsp%3B%20(where%20the%20default%20%5B%7BAppVPackageRoot%7D%5D%20points%20to%20the%20system32%20folder).%26nbsp%3B%20I%20previously%20commented%20that%20this%20is%20a%20horrible%20mapping%2C%20as%20one%20might%20set%20the%20package%20root%20manually%20in%20which%20case%20this%20points%20to%20a%20different%20place.%26nbsp%3B%20And%20that%20does%20need%20to%20be%20addressed%2C%20but%20I%20wasn't%20doing%20that%20here%20-%20I%20was%20not%20specifying%20the%20installation%20folder.%26nbsp%3B%20No%2C%20the%20possible%20cause%20is%20seen%20inside%20the%20editor%20where%20the%20captured%20file%20is%20actually%20mapped%20differently%2C%20as%20%22%5B%7BSystem%7D%5D%5Cconfig%5CSYSTEM.LOG1%22.%26nbsp%3B%20Which%20of%20course%20is%20a%20different%20folder%20(but%20also%20in%20the%20exclusion%20list).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESo%20it%20seems%20that%20the%20exclusion%20filtering%20is%20horribly%20confused%20by%20these%20variables%20and%20needs%20to%20be%20fixed.%20But%20at%20least%20with%20a%20work-around%20I%20can%20start%20packaging%20again!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319571%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319571%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20public%20release%20of%20the%20tool%20is%26nbsp%3B%3CSPAN%3E2018.1005.2324.0%2C%20which%20is%20the%20only%20update%20to%20date.%26nbsp%3B%20We%20will%20update%20the%20docs%20when%20a%20new%20version%20is%20released%20(and%20provide%20notes%20on%20some%20key%20changes).%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%3ELonger%20term%20we%20have%20an%20item%20in%20the%20backlog%2C%20lower%20priority%20at%20this%20time%2C%20to%20offer%20an%20in%20app%20notification%20if%20a%20newer%20version%20is%20available.%26nbsp%3B%20This%20would%20obviously%20require%20some%20connectivity%20to%20the%20internet%20to%20poll%20and%20let%20the%20IT%20Pro%20know%20a%20newer%20version%20is%20available.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EJohn.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-319554%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-319554%22%20slang%3D%22en-US%22%3E%3CP%3EJames%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20see%20this%20isn't%20the%20latest.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIt%20isn't%20easy%20to%20know%20when%20updates%20to%20the%20tool%20are%20available%20because%20we%20%3CSTRIKE%3Ekeep%20Windows%20Update%20disabled%20%3C%2FSTRIKE%3E%3CEM%3Edon't%20login%20with%20the%20MSA%20account%20%3C%2FEM%3Eon%20machines%26nbsp%3B%20we%20use%20for%20captures.%26nbsp%3B%20A%20notification%20to%20those%20getting%20access%20to%20the%20private%20builds%20would%20go%20a%20long%20way%20%3B)%3C%2Fimg%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-312797%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-312797%22%20slang%3D%22en-US%22%3EI%20am%20using%20build%201115.%20I'll%20go%20back%20and%20see%20if%20that%20isn't%20the%20latest.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-310034%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-310034%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Tim%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20assume%20you%20started%20seeing%20this%20issues%20on%20the%20November%20Insider%20flight%3F%26nbsp%3B%20I%20fixed%20some%20issues%20in%20this%20area%20early%20December%20that%20should%20address%20missing%20file%20or%20file%20in%20use%20errors%20while%20saving%20the%20package.%26nbsp%3B%20The%20December%20flight%20should%20have%20those%20fixes.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20you%20are%20still%20seeing%20such%20problems%20on%20the%20latest%20build%20of%20the%20tool%2C%20please%20let%20me%20know.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThanks!%3CBR%20%2F%3EJames%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308092%22%20slang%3D%22en-US%22%3ERe%3A%20MSIX%20Packaging%20Tool%20Failures%3A%20File%20not%20found%20issues%20(A%20workaround)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308092%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20for%20the%20feedback.%26nbsp%3B%20I%20filed%20an%20item%20for%20the%20team%20to%20look%20into%20this%20for%20the%20MSIX%20Packaging%20Tool.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EJohn.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
MVP

In packaging a lot of apps, I find that the Packaging tool fails quite often when saving the package.  In looking into the Log file, these errors are usually background system created files.  Like C:\Windows\System32\config\SYSTEM.LOG1 or LOG2.  Or those stupid wbem files.

 

Adding exclusions doesn't seem to help.  I even add them in the form shown, or in \\?\C:\Windows... form (as the log file hints at).  Still doesn't help.  Even though the files are in the exclusion list, they don't get excluded.  

 

One possible cause of this is hinted at by the workaround that I am using.  Rather than save the package off and have it fail, I find I must continue into the package editor.  From there I can manually look for potentially offending files and right-click delete them.  Then I can save the package off cleanly.

 

So what's the hint about the possible cause?  Well when you add an exclusion (on an x64 OS) to C:\Windows\System32\config\SYSTEM.LOG1, this exclusion is mapped to and saved as "[{AppVPackageRoot}]\config\SYSTEM.LOG1"  (where the default [{AppVPackageRoot}] points to the system32 folder).  I previously commented that this is a horrible mapping, as one might set the package root manually in which case this points to a different place.  And that does need to be addressed, but I wasn't doing that here - I was not specifying the installation folder.  No, the possible cause is seen inside the editor where the captured file is actually mapped differently, as "[{System}]\config\SYSTEM.LOG1".  Which of course is a different folder (but also in the exclusion list).

 

So it seems that the exclusion filtering is horribly confused by these variables and needs to be fixed. But at least with a work-around I can start packaging again!

 

 

 

 

 

5 Replies
Highlighted

Thanks for the feedback.  I filed an item for the team to look into this for the MSIX Packaging Tool.

 

John.

Highlighted

Hi Tim,

 

I assume you started seeing this issues on the November Insider flight?  I fixed some issues in this area early December that should address missing file or file in use errors while saving the package.  The December flight should have those fixes.

 

If you are still seeing such problems on the latest build of the tool, please let me know.

 

Thanks!
James

 

 

Highlighted
I am using build 1115. I'll go back and see if that isn't the latest.
Highlighted

James,

 

I see this isn't the latest. 

 

It isn't easy to know when updates to the tool are available because we keep Windows Update disabled don't login with the MSA account on machines  we use for captures.  A notification to those getting access to the private builds would go a long way ;) 

Highlighted

The public release of the tool is 2018.1005.2324.0, which is the only update to date.  We will update the docs when a new version is released (and provide notes on some key changes).

 

Longer term we have an item in the backlog, lower priority at this time, to offer an in app notification if a newer version is available.  This would obviously require some connectivity to the internet to poll and let the IT Pro know a newer version is available.

 

John.