User Profile
MikeH
Brass Contributor
Joined 5 years ago
User Widgets
Recent Discussions
Re: What is the "gap" and how do I eliminate it?
GrahamGBI think we concluded that it's some lazy attempt to avoid a race between the updater and the app shutting down, when it's detected that the app is still running. I run a company that makes packaging tools and we solved this by taking more control over the update process ourselves using the API. https://hydraulic.dev/ makes MSIX packages but also a small Win32 installer/updater exe that drives the install and update process itself. This lets us work around bugs in Windows.602Views0likes0CommentsRe: Purpose of Uap5:AppExecutionAlias vs Uap3
Presumably it sets the subsystem PE header in the synthetic executable, meaning that if the app being aliased is a command line app that needs to output text to the console, it should be "console" and if it's a GUI app it should be "windows".1.2KViews0likes1CommentRe: Winforms .exe in MSIX Package Does Not Startup After Auto Update
Hi Christophe, For apps packaged with Conveyor [1] we have a workaround: 1. We default to background updates, which don't have this issue. 2. We have a tiny Win32 app that drives the package manager via the WinRT/C++ API and then starts the app once complete. If a packaged program wishes to force an update and knows one is available e.g. from a server poll, it simply invokes the bundled EXE and then quits. The stub EXE then drives the install/upgrade process whilst showing a progress bar and app logo, and relaunches the app when done. This gives a similar experience to the built-in "check on start" mode, but with these caveats: 1. It's a feature of Conveyor, not MSIX. Therefore you must use Conveyor to package your app to get it. 2. It's not yet a fully launched/documented feature. You'd probably want our help to activate it. We should launch it soon though. 3. It's up to your app to notice there's a new version available and trigger the update process. For example by doing a quick poll whilst showing a splash screen. We don't block startup like the AppInstaller integration will do, because you may wish to overlap the update check with things like logging in to a server, instead of adding app latency every single time. You can see a short looping video of what the installer EXE looks like on our website: https://hydraulic.software/1.5KViews0likes0CommentsNew easy and cross-platform packaging tool that supports MSIX
https://hydraulic.software/ is a new packaging tool that makes it easy to distribute desktop apps across multiple platforms. It's primarily focused on developers who use cross-platform frameworks like Electron or the JVM, but can also be used for native apps. For Windows users it creates MSIX files and if you want to, you can use it as an alternative to the Microsoft toolchain for building MSIX packages. The main reasons to consider doing that are: You can build and sign MSIX files from any OS including e.g. Linux CI machines. It generates nice download HTML pages for you. It uses a simple but powerful superset of JSON for configuration. You can check for and then force upgrades easily by just polling your download site URL to find the latest version. If you then decide to upgrade, you just run a small EXE that gets bundled with your app at packaging time and then shut down - the little EXE will show the user a download progress bar, perform the update and then restart you automatically. You don't need any custom C# or other Windows code. Conveyor works around various bugs in Windows automatically. It's important to understand that Conveyor isn't a general purpose "repackager". It doesn't take any arbitrary program and turn it into an MSIX. Although you could use it that way, it's focused on the subset of programs that don't do anything too complex w.r.t. OS integration, and expects you to specify in a config file what the package should contain and do. It's intended for apps or developers that value an easy to use and cross platform tool.975Views0likes0CommentsRe: Winforms .exe in MSIX Package Does Not Startup After Auto Update
Thanks to Lars for repro steps. Roy_MacLachlan - to get everyone on the same page, can you find out what exact version of Windows and AppInstaller your developer is using? Let's rule out the possibility that you've already got it fixed in a build we're not using. Or better, ask your dev to come here directly so we can iterate faster? I haven't tried to repro it lately, but I'll try to get an independent set of repro steps next week.2.6KViews0likes0CommentsSub-optimal shutdown testing implementation?
Hello, Would it be possible for the MSIX team to upgrade the "force app to shutdown" implementation? I noticed that when Windows shut downs an app so it can be upgraded (when AddPackageByAppInstallerOptions::ForceTargetAppShutdown is specified) there is a pause that's always exactly 30 seconds in length. It feels like rather than poll to find out when the app shutdown has finished and the package is no longer in use, whoever wrote this code just whacked the moral equivalent of a Thread.sleep(30_000) in there or something. It's quite an ugly UX as a consequence because the user is simply left waiting. The installs do complete, so it's not technically a bug, but it seems kinda disrespectful to make the user stare at a progress bar for 30 seconds. And yes, I have submitted a feedback hub entry about this - https://aka.ms/AAhkqj7 - complete with screen recording so hopefully you can see what I mean (this install uses a custom UI but it's the AppInstaller API behind the scenes). I've solved this for now by simply shutting the app down myself without relying on the force shutdown flag anymore, before invoking the custom UI I have that wraps the PackageManager API. Then it's all very nice and snappy.652Views1like1CommentRe: WebView2 external dependency cannot be installed from an MSIX package on a Windows 10 target machine
Daniel1175 This error can happen if you re-sign the installer or pass incorrect parameters to it. See: https://github.com/MicrosoftEdge/WebView2Feedback/issues/1582 Are you re-signing the installer with your own certificate?5KViews0likes9CommentsRe: Winforms .exe in MSIX Package Does Not Startup After Auto Update
Oh, sorry, I just realized that this is the thread where we're reporting it. @Roy - that isn't the right set of reproduction steps indeed. Can you please try again? 1. Try the instructions provided by Lars. App not running at the time. 2. Try the instructions provided by me. Specifically, what I reported was that this happens when the appinstaller is configured to check for an update on every single launch, and then you start the app from the start bar with a pending update. You may also need to fiddle around with this quite a bit because it seems like you have to do something specific to get Windows into such a state. It might also be worth just asking the developers to read the code carefully and see if they can spot any way in which this can happen.2.7KViews0likes12CommentsRe: MSIX package App icons and logos problem
Thanks for checking 🙂 I guess my problem is something else then, as I can see the .pri file contains these alternative forms and sizes correctly yet Windows still doesn't seem to use them. Very obscure. It seems Microsoft has given up on "plating" as none of the taskbar icons in Windows 11 seem to have such a border.3.7KViews0likes0CommentsRe: MSIX package App icons and logos problem
Hi Bogdan, if you see this, do you recall what the issue was here? I face the same problem with my MSIX files - even after generating altform-unplated.png versions and making a resources.pri file, the border will just not go away. I wonder if there is some obscure thing that isn't well documented.3.8KViews0likes2CommentsRe: The ms-appinstaller protocol has been disabled.
The workaround is for users to download the XML file and open it. If you need the custom parameters then there's no workaround. If you don't need custom parameters then it's worth maybe taking a deep breath and looking at the actual UX change. Before: 1. Click the link. 2. Click the yes button in "Open this link in App Installer?" 3. Click Install/Launch in App Installer. After: 1. Click the link. It downloads. 2. Click the download in the browser. App Installer opens. 3. Click the Launch/Install button. Same number of clicks. The URL handler _is_ better because it has more features, because the permission to open URLs is remembered per site, because URLs work in more places, because it doesn't clutter the user's downloads folder and so on. So we all hope it'll return. But, for distribution via a web page, the difference isn't that large.10KViews0likes2CommentsRe: UpdatePackageAsync fails with FileNotFoundException
Ideas: 1. Do you see any attempt to contact the server in your server logs at all? 2. Does the URI contain any weird characters or other things that could be confusing it? 3. Does the URI point to an .appinstaller file (might be broken at the moment by the ms-appinstaller:// screwups) or an MSIX file? Try both?1.4KViews0likes1CommentRe: Bad experience with app container virtualization and workarounds
Thanks. I haven't tested signed-but-unpackaged, I'll do that once I finish my current pile of bugs. I've found a workaround for the subprocess/VFS issues. If sub-processes are run in the redirected path then they seem to work properly, or at least cmd.exe does. So that leaves the question of how to know where the redirected path is. My solution is to, at startup in native code, change the values of the LOCALAPPDATA and APPDATA environment vars (which my app uses) to be the output of SHGetKnownFolderPath with the KF_FLAG_RETURN_FILTER_REDIRECTION_TARGET flag. This returns the path that Windows is redirecting writes to. By using this location directly instead of relying on the redirection, it appears to have fixed my issue. The nice thing about this is, it will automatically work for any program that uses the right environment variables in the process tree. This preserves the VFS functionality whilst working around whatever bug is breaking things.2.5KViews0likes0CommentsRe: Bad experience with app container virtualization and workarounds
Bogdan Mitrache Thanks for the tips. I tried Hover, thanks for releasing it, it's a nice app. I noticed it uses MSI 😉 Actually the kind of no-fuss one-click install you've got with Hover is pretty much what I'd like to have, are you making that using WiX?, that's being made with your Advanced Installer product, right? W.R.T. notepad the actual use case in my app is viewing or sending/attaching a log file. So read-only is fine. It looks like you guys developed a fixup that can modify command line arguments, is there a Win32 API to devirtualize file paths? I haven't yet experimented with the manifest feature that lets you expose files to other apps, perhaps that's the way to go. Re: running inside the container. Do you or anyone else know how this PowerShell Cmdlet works internally? Again, is there a Win32 API for this? Or is running a PowerShell sub-process actually the official API for doing this kind of thing? Is there a way to make sub-processes reliably run in the same container by default? The docs suggest it should happen automatically but obviously that isn't the case. In my case, my app is running "cmd /c 'some command'" and it's cmd.exe that complains it can't find the directory, presumably because it's been started outside the container. W.R.T. not using AppData - yeah, I know why AppData is there and it will cause problems not to use it because the files in question are actually mostly a large file cache. It's not really user data and the only reason to write it to the home dir is to escape the virtualization layer whilst still having a GUI install. So it won't roam well and I'm already looking for workarounds there, like maybe finding a cache directory under c:\windows or something like that. It needs to be somewhere sub-processes work because I invoke them inside this large private file tree. Finally, with the virus scanner, I understand that malware authors can buy or steal signing keys, but then that rather suggests that the whole idea of revoking malware keys or using them for legal enforcement is a bust. If Microsoft want their operating system API to heuristically guess whether to allow basic low level operations or not, then it needs a top-class debugging and diagnostics experience. The app works fine when it's not signed and running outside of the installed version, presumably because it's a Java app and so perhaps the high-reputation JVM signature takes precedence. The moment I sign it, the app breaks in subtle ways that only show up during a full test cycle, without any information that it's done so, in ways that are difficult to debug. I will probably try signing it with an EV key next.2.5KViews0likes2CommentsBad experience with app container virtualization and workarounds
The MSIX filesystem/registry virtualization sounds like a good idea on the surface but isn't usable for some sorts of apps. This post is a warning to other developers about what can go wrong, and hopefully a wakeup call to Microsoft. You guys are being too ambitious and keep shipping features that are buggy. Problems, in no particular order: The virtualization is justified on the grounds of helping Windows uninstall apps and clean up their data, but it also breaks common use cases like opening Notepad to edit a config file or show logs because Notepad can't see the file. Getting apps to run "inside" the container is painful. Windows has no support for this. MSIX Hero can do it, sometimes, and sometimes not. Explorer will let you see the package-specific directories but sometimes will show them as empty even if they aren't, etc etc. Generally this feature breaks a lot of stuff you'd expect to work and makes it hard to get access to your app's own files. Bugs in the app container / virtualization system can cause sub-processes to make complaints like "invalid working directory" when started inside a normal AppData path. No problem, you think. Luckily the manifest lets you disable the virtualization. It's just a little bit of XML. Sure enough this fixes the execution bugs, but .... Now AppInstaller refuses to install the MSIX! There's apparently no technical reason for this - it merely chooses not to, because in Microsoft's esteemed opinion only antisocial deviants would want to do this. You can install such an MSIX from the command line only. Even when that one is fixed (see below), that doesn't mean file IO will be reliable. Oh no. Even though the EXEs, DLLs and the MSIX itself are signed, Windows Defender will still randomly cause file IO operations to fail in apparently "impossible" ways, without any notification it's doing this whatsoever, for instance just randomly failing to copy a file half way through a tree copy operation. I had to figure this one out by using Processor Monitor and some lucky guesses. What's the point of signing software if Windows will still treat it like malware anyway? Combined with the sudden yanking of ms-appinstaller://, the total lack of useful communication about when it'll be back, the caching bugs etc, you guys are simply punching developers in the face at this point. The whole reason I'm trying to opt out of virtualization is because your OS is full of bugs, not because I have an inexplicable fetish for leaving temporary files behind after uninstallation. If the feature worked we'd use it. Fortunately there are some simple workarounds in this case: don't write files into AppData. If you're writing software that will be distributed using MSIX I strongly advise taking this path, or at least setting things up so that it's easy to do so. Write files into the user's home directory instead. The App Installer team have apparently not remembered that this is possible and their attempts to "force" developers to make files removable during uninstallation are pointless as a result.2.7KViews0likes4CommentsRe: Winforms .exe in MSIX Package Does Not Startup After Auto Update
A bit more info: I got Windows into a state where I could reproduce this 100% of the time. The AppInstaller XML used was below. The AI log showed no problems, which isn't a surprise as the bug seems to be in the start/taskbar code. I didn't see my app EXE in task manager, not as a background task or anything else, and disabling background tasks makes no difference. Although I thought this was related to the "gap" in the AppxDeploymentServer logs, I can reproduce this also without any large values in the gap timings. In fact there is no timing issue involved here, even though it seemed that way at first. Careful testing shows that in my case, the app will never start until the start menu or search bar is interacted with, at which point it starts immediately. Interacting with other parts of the taskbar doesn't trigger this. It doesn't matter how long I wait after an upgrade - if I don't touch search or start button, the app will not launch after an upgrade. If I open the start menu I don't have to re-launch my app from there or do anything else. The mere act of clicking on it will cause the app to launch, and in fact, when it does it will steal focus and thus the start menu will disappear again. However after changing my AppInstaller XML to disable the prompt, doing a couple of upgrades, and then changing it back the problem has gone away. Now Windows starts the app after an upgrade successfully. To me this smells like another caching bug: perhaps Windows isn't handling changes to the OnLaunch settings properly and the taskbar/AppInstaller components can get confused about what update modes the app is meant to be using? XML: <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/> <AutomaticBackgroundTask /> <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion> I noticed from reading the documentation that the way App Installer is invoked doesn't seem very deeply integrated with Windows. Supposedly the upgrade check is done only if the taskbar is used to launch the app. If you have e.g. a shortcut on your desktop, and use that, then App Installer doesn't get involved at all. Or if any other process starts your app, same thing, the update check isn't done. Therefore what seems to be happening is something like this: The taskbar/start menu code is asked to launch an app controlled by AppInstaller. It consults its timeout list and notices it's time to do an update check. It passes control to App Installer to do the update and waits for a signal that the update has been completed. AI sends that signal (somehow). Something goes wrong: the Start code has been put to sleep in a way that it doesn't wake up when the signal arrives. Interacting with the taskbar in such a way that the list of app icons is pulled up, re-awakens that part of the code, which then notices the signal from App Installer and continues with the launch of the app. This doesn't happen on every code path. If an update check is done but no update is required, the launch works OK (but that might be a timing-caused red herring?). A workaround is to disable the prompt using ShowPrompt="false" and go to fully silent upgrades i.e. with background upgrades only. This means that if an update has just been released and the user starts their app, it will be the old version and the next start will be upgraded, but, this is only a short window of time as after 8 hours Windows will (supposedly) apply the upgrade in the background anyway. Fully silent upgrades are what Chrome uses so this is an acceptable workaround for now - it is only an issue if the app needs to be forcibly upgraded to match e.g. a protocol change on a server. In that case the app itself may need to figure out by itself if it's fully up to date or not and if not, restart itself to re-load the updated code - possibly monitoring the AppX logs to figure out when Windows has finished applying the upgrade.5.6KViews2likes25Comments
Recent Blog Articles
No content to show