Wix installer uninstaller issue when a bundled app is skipped - wix

I have a bundled application say XYZ-1.0.0.1.exe, with applications A-2.2.0.1.exe and B-1.2.0.1.exe bundled in it. So when we install XYZ, we get A and B as well listed in Add Remove Programs. But when I upgrade XYZ-1.0.0.1 with XYZ-1.0.0.2, which has A-2.2.0.1.exe and B-1.2.0.2.exe, so that A is same and already installed and B needs upgrade. I actually skipped the installation of A by making the install condition false, since the same version is already installed and installed only B while upgrading.
After successfully upgrading I am not able to uninstall the application XYZ, it says some package error, also this happens only if the source file used for upgrading is removed from machine.Actually while uninstalling package has to be referred from program cache, I think since we skipped A package cache has problem.
The error that i get is as follows "Prompt for source of container: WixAttachedContainer, path: C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe Failed to resolve source for file: C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe, error: 0x80070002. Error 0x80070002: Failed while prompting for source (original path 'C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe'). Failed to acquire container: WixAttachedContainer to working path: C:\Users\ABC\AppData\Local\Temp{b4a1c780-306c-40f0-83ad7}, error: 0x80070002. "
This error occurs only when i copy XYZ.exe to any path say desktop and after installation(skip installing A or B since same version of A or B bundled is already installed) and delete the setup file XYZ.exe from saved path ie here Desktop. I am not able to uninstall unless i uninstall A or B which was skipped independently.
Also there is another scenario.
I have a bundled application say XYZ-1.0.0.1.exe, with applications A-2.2.0.1.exe and B-1.2.0.1.exe bundled in it. XYZ-1.0.0.2.exe, which has A-2.2.0.1.exe and B-1.2.0.2.exe. Thes in both versions of XYZ we have the same version of A. When i install XYZ-1.0.0.1.exe i skipped the installation of A-2.2.0.1.exe by setting the install condition to false. So XYZ-1.0.0.1.exe is installed and B-1.2.0.1 is also installed. Further when i upgraded to XYZ-1.0.0.2, I need to install all of the A and B. Installation was successfull and now i have XYZ-1.0.0.2, A-2.2.0.1 and B-1.2.0.2. Now if i delete the installation file of XYZ-1.0.0.2.exe from original path and try to uninstall it breaks.
Initially i thought that the package cache issue arises since A-2.2.0.1.exe was not installed along with XYZ-1.0.0.2.exe since i skipped it as it is already available. But after the second scenario got to know that skipping was not the issue. Since in second scenario A-2.2.0.1.exe was installed along with XYZ-1.0.0.2.exe.

The same issue took huge amount of my time as well. Solved it using a work around. Since the issue is "Prompt for source of container: WixAttachedContainer, path: ", You can copy the exe file XYZ-1.0.0.2 while upgrading to program data or some other path with a default name xyz.exe. At first register for ResolveSource event,then add the following code.Assume the copied exe path is c:/XYZ/xyz.exe
private void OnResolveSource(object sender, ResolveSourceEventArgs e)
{
Application.Engine.SetLocalSource(e.PackageOrContainerId, e.PayloadId, "c:/XYZ/xyz.exe");
e.Result = Result.Retry;
}
If anybody know a better answer, please help.

Related

Where is the Windows App Runtime for V1.1.2 (particularly the DDLM component), please?

NuGet delivered the Microsoft.WindowsAppSDK v1.1.2 yesterday (2022-07-02). My updated WinUI 3 programs now produce the following message when run:
This application requires the Windows App Runtime Version 1.1
(MSIX package version >= 1002.543.1943.0)
I uninstalled previous versions of the runtime and ran the suggested installer (from an elevated PowerShell prompt):
Installing license: MSIX_MAINPACKAGE_LICENSE
Install result : 0x0
Installing license: MSIX_SINGLETONPACKAGE_LICENSE
Install result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.1_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.1_1000.516.2156.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: MicrosoftCorporationII.WinAppRuntime.Main.1.1_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: MicrosoftCorporationII.WinAppRuntime.Singleton_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x6_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x8_1000.516.2156.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
All install operations successful.
Although none of the package FullNames included the sought-for version number 1002.543.1943, this was the result:
(get-appxpackage micro*win*appruntime*).packagefullname
Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x86__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Main.1.1_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x6_1000.516.2156.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Singleton_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x8_1000.516.2156.0_x86__8wekyb3d8bbwe
All of the components are of the required version except for the DDLM components (note that if you do not run the installer as an administrator, you only get the 1002 version of the principal runtime components. The .Main* and .Singleton* will be _1000.516.2156).
The problem is, the programs are looking for that DDLM module and they both have an MSIX version number of 1000.516.2156.0 (although they also have a dependency on Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x??__8wekyb3d8bbwe).
Does anyone know where I can get an MSIX for the 1002.543.1943.0_x?? DDLM component of the runtime? Or a runtime installer that contains all of the components with the required version number?
Thanks for any help.
As of today (2022-07-05), the download links on the official Microsoft page (Downloads for the Windows App SDK) contain all of the correct versions for the latest update (v1.1.2) to the Windows App Runtime.
Just a note: I removed all of my prior installations of the runtime from a PowerShell prompt before running WindowsAppRuntimeInstall.exe. Running (get-appxpackage micro*win*appruntime*).packagefullname reported no packages but trying to install the new runtime still gave me an error (package already installed but has different contents than the installed version). Although I am the only user of this machine, previous installs added the runtime to system accounts.
To see all installations, run (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname from an elevated PowerShell prompt. Look for versions of the runtime with versions of 1002., DDLM.1001, and DDLM.1000. These may be the culprit as they were all in various versions of the runtime installer (v1.1.2) after it first dropped on July 1st. To remove them from all users, run Remove-AppxPackage -AllUsers -PackageName {package full name}. After removing versions that might have been in the "naughty" packages, try running the new WindowsAppRuntimeInstall.exe again. Everything should work.
What I have learned (thanks #aturnbul) is that to ensure a correct framework package update:
Close the WinUI 3 gallery and any other app using the framework.
Using the PowerShell commands listed by aturnbul remove all older packages
Run WindowsAppRuntimeInstall.exe from an elevated command prompt, so you can see any error that it may throw.
Back in PS you can verify that the installation was complete.
// After a failed installation you get only a partial list of packages
PS C:\Windows\system32> (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
// After a successful installation you get all the packages
PS C:\Windows\system32> (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Main.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Singleton_1004.584.2120.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1004.584.2120.0-x6_1004.584.2120.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1004.584.2120.0-x8_1004.584.2120.0_x86__8wekyb3d8bbwe

Visual studio code error :-Failed to start flow Error: Wrong version of Flow. The config specifies version ^0.92.0 but this is version 0.95.1

Hello I am a beginner in React-native and below is my flowconfig file's version and I get an error with this version
[version]
^0.92.0
Is there a way to fix this error, I was trying to run debug mode in visual code for running react-native projects and to print console.log.
So far I am unsuccessful.
PS:- beginner in react-native
Change [version] in the .flowconfig to match the installed version, ^0.95.1
1. Check that the following tags match
package.json
"devDependencies": {
"flow-bin": "0.130.0"
}
.flowconfig
[version]
^0.130.0
2. Clean & Reinstall
If they match, this error can occur when your node_modules are out of sync with the version of flow-bin in your package.json. This can occur if you've changed branches recently or have have an older version in your node modules.
Try removing and reinstalling like this:
rm -rf node_modules/ && npm i
Instead of changing the flow version make it a ranged version. For example something like >=0.50.0 or simply remove the version altogether. You can read about that more in the flowconfig docs
I find that changing the flow version every time you face this problem to be a bad approach especially if you work with a team and each team member has a different version installed and they would commit their version into the .flowconfig file

Paket won't download logary on install

Im admittedly a pretty big paket noob.
When I run mono paket.exe install
I get
Paket failed with
-> Could not download from 'https://raw.githubusercontent.com/logary/logary/31e0650902a9c7f92aa90b0b5474a551e6282a7e/src/adapters/Logary.Adapters.EventStore/EventStore.Logary.fs'
-> RequestFailedException: Request to 'https://raw.githubusercontent.com/logary/logary/31e0650902a9c7f92aa90b0b5474a551e6282a7e/src/adapters/Logary.Adapters.EventStore/EventStore.Logary.fs'
failed with: 'NotFound'
However, if you navigate to those links the files download just fine. I'm not sure why it's failing.
Also, even if those files exist already, paket will remove them, then fail to download them once more.
In this case it's because the EventStore adapter was upgraded to .Net core and thus unavailable for a while. But it should not be a problem if you had dodged this:
There's a known bug in paket for file dependencies with paket install that always downloads the latest file no matter what is in the lock file, unless the file reference is pinned.
So: pin the file, like so: https://github.com/SuaveIO/suave/blob/master/paket.dependencies#L17
github logary/logary:c70468f60602e1ab954a38e574b946d4ffbda11d src/Logary.Facade/Facade.fs

Installing kdesu on NixOS

When setting advanced properties on a program/link to start as another user it is throwing the error:
Sorry - Plasma
KDEInit could not launch 'kdesu':
Could not open library 'libkdeinit5_kdesu'.
Cannot load library /run/current-system/sw/lib/libkdeinit5_kdesu: (/run/current-system/sw/lib/libkdeinit5_kdesu.so: cannot open shared object file: No such file or directory)
I tried to install kdesu using:
[root#nixos:~]# nix-env -qaP kdesu
nixos.kdeFrameworks.kdesu kdesu-5.36.0
[root#nixos:~]# nix-env -iA nixos.kdeFrameworks.kdesu
replacing old ‘kdesu-5.36.0’
installing ‘kdesu-5.36.0’
building path(s) ‘/nix/store/2bn27h5drw0800gk5z2rmwfx78gqbbdc-user-environment’
created 2209 symlinks in user environment
[root#nixos:~]# kdesu
bash: kdesu: command not found
[root#nixos:~]# which kdesu
which: no kdesu in (/root/bin:/run/wrappers/bin:/etc/per-user-pkgs/root/bin:/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
I also tried installing nix-env -iA nixos.kde-cli-tools but that does not work either.
Any suggestions on how to get kdesu installed on NixOS?
As a general rule, unlike many distros on NixOS installing a library directly doesn't work as intended; the application that needs the library won't be able to find it. Instead, the package must declare all it's dependencies.
Packages which have optional dependencies tend to have a way to add them via configuration. You may want to try something like this in /etc/nixos/configuration.nix
services.xserver.desktopManager.plasma5.extraPackages = with kdeFrameworks;
[ kdesu
];
I'm glad to see that you filed an issue on Nixpkgs, because this is not a configuration issue but a packaging bug.
It looks like kdesu lives in some libexec dir that doesn't hasn't been added to your PATH. It belongs to the kde-cli-tools package. You can run it with
$(nix-build '<nixpkgs>' -A kde-cli-tools --no-out-link)/lib/libexec/kf5/kdesu
You can use the above as an alias to launch kdesu until the fix to the packaging bug arrives.

Homebrew doctor crashes

I just upgraded & updated my homebrew and now if I run brew doctor, I get the following errors and it fails to run. May I deleted the unexpected header files or is there a better solution?
Warning: Your XQuartz (2.7.6) is outdated
Please install XQuartz 2.7.7:
https://xquartz.macosforge.org
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/node/ares.h
/usr/local/include/node/ares_version.h
/usr/local/include/node/eio-emul.h
/usr/local/include/node/ev-emul.h
/usr/local/include/node/node.h
/usr/local/include/node/node_buffer.h
/usr/local/include/node/node_object_wrap.h
/usr/local/include/node/node_version.h
/usr/local/include/node/uv-private/eio.h
/usr/local/include/node/uv-private/ev.h
/usr/local/include/node/uv-private/ngx-queue.h
/usr/local/include/node/uv-private/tree.h
/usr/local/include/node/uv-private/uv-unix.h
/usr/local/include/node/uv-private/uv-win.h
/usr/local/include/node/uv.h
/usr/local/include/node/v8-debug.h
/usr/local/include/node/v8-preparser.h
/usr/local/include/node/v8-profiler.h
/usr/local/include/node/v8-testing.h
/usr/local/include/node/v8.h
/usr/local/include/node/v8stdint.h
Basically, you just need to upgrade the XQuartz in your system and ignore all the other warnings.
You may build some software that utilise X11 components, so just go to https://xquartz.macosforge.org/, download and install the latest version.
It is obvious that you install node.js without using homebrew so that the header files are added into /use/local/include/ not via homebrew and confuse it. Unless you encounter some kind of problems as mentioned in the warning message, you can just ignore them.