We have an installer system based on a WIX built MSI. The boot strapper is NSIS. It is just the way things went. And it all works fine now but for one little glitch.
There are two NSIS installers. One for new users. That runs the MSI conventionally so they contract screen can be agreed to. The the app checks for updates and the user can do just that. This is the second NSIS package for that:
Section -RA_unzip
InitPluginsDir
ReadRegStr $R1 HKCU "Software\Company\AppFolder\Property" "User Directory"
SetOutPath $R1
File "f:\cpp\AppName\deployment\AppName.msi"
ExecWait 'msiexec /i "$R1\AppName.msi" /L* msi.log /passive /norestart' $0
SectionEnd
Section -r_name_dlls
ReadRegStr $R0 HKCU "Software\Company\AppFolder\Property" "Program Directory"
Rename $R0\libssl_3.dll $R0\libssl-3.dll
Rename $R0\libcrypto_3.dll $R0\libcrypto-3.dll
SectionEnd
Section -Finishing Up
Sleep 1000
SectionEnd
Section -restartRA
ReadRegStr $R0 HKCU "Software\Company\AppFolder\Property" "Program Directory"
Exec $R0\ars.exe
Quit
SectionEnd
Less than half of the time the application comes up to the top of the Z-order. Sometimes it ends up at the bottom! This happens on my Windows7 and my wife's Windows10. If I run this without bumping the MSI version, (It just quits without an install), then the app window will always make it to the top.
I've even added BringWindowToTop(*GetMainWnd()); at the end of initialization when the main window is well established and running. And I did think it had something to do with the windows installer being slow to leave, that is why the Sleep 1000. It made no difference.
The only thing that is for sure is it happens when the windows installer actually does an install.
Calling Quit directly after Exec is not a good idea because if the installer quits before the child process has displayed its window the right to set the foreground window is lost.
You could try
ExecShell /WAITFORINPUTIDLE "" "$R0\ars.exe"
Sleep 1000
Quit
Related
Before reporting to Microsoft I want to ask here. I have a problem that I cannot see Live Visual Tree of my WinUI 3 application. I cannot even see the in-app toolbar. I can see both in WPF and UWP application, no problems. I have these options for hot reload, that should be fine.
I am using VS2022 17.3.1 and Windows App SDK in version 1.1.4. Weird is that it was functioning without problems, but one restart of application just broke that. I also tried adding the ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO to environment variables manually, but no luck there.
It seems that 32-bit WinUI 3 app is working fine, it only affects 64-bit WinUI 3 applications. Even the new and blank ones. Packaged/unpacked type doesn't affect the problem.
I tried uninstall and install VS again, no changes.
So I did finally find a solution (more of a workaround) to this.
Run following commands in elevated cmd, where you replace WindowsAppRuntime version with version you currently have (for me it is Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe):
takeown /f "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /r /d y
icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe" /grant Users:(RD,R,REA,RX) /t
Don't know what it does, but it is working. This solution is taken over from Developer Community
UPDATE:
You have to repeat this procedure when you update Windows App SDK to a new version.
Here is a PowerShell command that loops over all WindowsAppRuntime folders and applies the fixes on #benderto's answer.
Get-ChildItem -Path 'C:\Program Files\WindowsApps\' -Filter 'Microsoft.WindowsAppRuntime*' | Foreach {
takeown /f "C:\Program Files\WindowsApps\$_" /r /d y
icacls.exe "C:\Program Files\WindowsApps\$_" /grant "Users:(RD,R,REA,RX)" /t
}
You don't need to restart Visual Studio for this to take effect. Restarting the debugging session is enough.
After lots of reinstallion, 100+?, I came across with this information then problem solved.
It is very frustrating the recent quality of Visual Studio 2022 after 17.2. Each update gets me reinstall loops again, again and again, just because something broken.
This time, MAUI (WinUI 3) XAML Hot Reload won't work.
XAML Hot Reload
So I created 3 VMs and installed with different detail of workloads, and tried to figure out "What's wrong". But I failed.
The error seems random. However, I did get some thing strange.
The Hot Reload was "working" after installaion and I left the VM on. After awhile back, I stopped debugging and restarted to debug, the working one became "not working" somehow over time, so I compared two snapshot, one work, one did not. After comparing installion configuration, run with user, run with admin, MAUI App with .net 6.0, MAUI App with template 7.0, both registry, both disk contain (entire C:). I found nothing, all identical as they should be.
Checking Logs:
Event Log, AppData\Local\Temp\VSLogs, AppData\Local\Xamarin\Logs\17.0, the Output of VS
However, the Output: debug. Did make me tracing the component binding process, also found nothing.
The One "Not Wotking":
The One "Not Wotking"
The One "Working":
The One "Working"
Huge data but no luck:
Assembly binding log
Windows Policy, no luck: Audit Access Deny
I have to say the error logs are well hidden.
After lots of google thing, I came across with this information then problem solved. It is a Permission problem.
And then I dig a little further, here i found:
VS Output:
WindowsAppRuntime, installed at first run, may be update after
C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe
The list of files that Permissions are different (Not Working vs. Working):
CoreMessagingXP.dll
dcompi.dll
dwmcorei.dll
DwmSceneI.dll
DWriteCore.dll
marshal.dll
Microsoft.DirectManipulation.dll
Microsoft.Foundation.winmd
Microsoft.Graphics.winmd
Microsoft.InputStateManager.dll
Microsoft.Internal.FrameworkUdk.dll
Microsoft.UI.Composition.OSSupport.dll
Microsoft.UI.Input.dll
Microsoft.UI.Windowing.Core.dll
Microsoft.UI.winmd
Microsoft.Web.WebView2.Core.dll
Microsoft.Web.WebView2.Core.winmd
resources.pri
WindowsAppRuntime.png
WindowsAppSdk.AppxDeploymentExtensions.Desktop.dll
wuceffectsi.dll
en-GB\Microsoft.ui.xaml.dll.mui
en-GB\Microsoft.UI.Xaml.Phone.dll.mui
Microsoft.UI.Xaml\Assets\NoiseAsset_256x256_PNG.png
Conclution:
The "Microsoft.WindowsAppRuntime" will get installed on first run and will not get uninstalled with Visual Studio uninstallation.
The "Microsoft.WindowsAppRuntime" may get updated and permission also get changed.
The ACL permission of Microsoft.WindowsAppRuntime folder and files in it may change somehow after some time, same version (Did not go this far to see why).
Manipulate the Permission manually does the trick
Simple Rest (SYSTEM access right is required, PsExec):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\*.*" /reset /t
Minimun Reset (for my case, as soon as this reset done, the hot reload shows up when debug, remember to restart debug):
psexec64 -i -s cmd.exe /k icacls.exe "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe\Microsoft.Internal.FrameworkUdk.dll" /reset
I created an VSTO Outlook app for my job. The thing is, we need to deploy that to users without any user interaction, so in other words, silently.
I know that we can use VSTOinstaller.exe located in %commonprogramfiles%\microsoft shared\VSTO\9.0\ and use it like so in a command line VSTOinstaller.exe /install "Path_to_the_VSTO_file" /silent.
But when I do this, nothing happens, no error message and no install.
However If I remove the /silent arg, it launch the VSTO and prompt me if I want to install the app.
I tried changing the arg with /I, /i, /S or /s but nothing change.
My app is sign with a valid cert and when we get prompt, we can see the green logo
I've look at many threads about silent install for that, but it's always the same.
Do I do something wrong? Is there any other way to do that silently?
Thank you!
I used WiX to build an installer (MSI) for an application, which works fine, except for this unreasonable amount of "applications that are using files that need to be updated by this setup":
This happens for some users some times, and I don't quite understand why this happens, and how to fix it.
I don't see a reason that the installation process of my application would conflict with all of these applications, and I'm not sure how to investigate it further.
My application is a standalone desktop application - not any add-on or something that interacts or depends on any of the applications listed.
The steps my installation process does:
Check that .Net framework 4.0 CP is available (exit if not).
Install the application under Program Files[Company][Product] (including my exe, my DLL, 2 third party DLL's that I bundle)
Install MS Visual C++ Runtime Redist 14.0 if needed
Add Start menu items for the application (launch & uninstall shortcuts)
Custom action for creating a scheduled task that starts my application on user logon as admin (the application runs in the tray as admin).
Custom action for starting the application after setup finishes (if checkbox is checked in last dialog).
Any advice on how to fix this, or at least investigate what causes this, will be appreciated :-)
Does it happen only when you run the installer and your desktop application is already running?
To investigate this further, best place to look at is your log file. The log file will have the details about the file which is being held by the other process, something like:
Info 1603. The file C:\...\abc.exe is being held in use by the following process: Name: xyz, Id: 19010, Window Title: 'xyz'. Close that application and retry.
Info 1603. The file C:\...\abc.dll is being held in use by the following process: Name: xyz123, Id: 9243, Window Title: 'xyz123'. Close that application and retry.
Once you determine the actual file being used by those other process, then it will help you figure out what the root cause is. Basically the INSTALLVALIDATE windows installer action determines if one or more files to be overwritten or removed are currently in use by an active process. An entry is added to an internal FilesInUse table if any file is overwritten or removed while it is open for execution or modification by any process during File costing. The FilesInUse table contains columns for the name and full path of the file. When the InstallValidate action executes, the installer queries the FilesInUse table for entries and determines the name of the process using the file. The InstallValidate action adds one record to the ListBox user interface table for each unique process identified by this query.
Ok, I have a simplified version of my nsi script (see below). In the A2 section, I copy a single executable to the specified installation path, create environment variables, then do a SendMessage which is supposed to make all currently running processes aware of the env change. However, it seems that the NSIS installer process itself doesn't get updated because the shortcut I create in the Links section doesn't work
installer.nsi:
SetCompressor /FINAL zlib
!include LogicLib.nsh
!include WinMessages.nsh
!include x64.nsh
!define ENGINE "TEST"
!define DERIV "A2"
!define LIB_VER "v43"
!define RELEASE "v3dev2"
Name "${ENGINE}${DERIV} DTE ${RELEASE}"
OutFile "${ENGINE}${DERIV}-DTE.exe"
; display the installation directory page
; note that NSIS places the selected directory in $INSTDIR
; DirText ""
Page directory setDefaultInstallDirectory
Function setDefaultInstallDirectory
;check for an existing sim root and set it as
the default installation directory if it exists
ReadEnvStr $1 SIM_ROOT
${If} $1 != ""
StrCpy $INSTDIR $1
${EndIf}
FunctionEnd
; display the installation page and show a message
; when the installation is complete
Page instfiles "" "" finished
Function finished
MessageBox MB_OK "Installation Complete."
FunctionEnd
section "A2"
SetOutPath $INSTDIR\${ENGINE}\${DERIV}
File alt_control.exe
; Environment Variables
WriteRegStr HKCU "Environment" "SIM_ROOT" "$INSTDIR"
WriteRegStr HKCU "Environment" "ENGINE" "${ENGINE}"
WriteRegStr HKCU "Environment" "DERIV" "${DERIV}"
WriteRegExpandStr HKCU "Environment" "RUN_DIR" "%SIM_ROOT%\%ENGINE%\%DERIV%"
; Broadcast to all processes that they need to update their environment
; http://forums.winamp.com/showthread.php?t=118501
SendMessage ${HWND_BROADCAST}
${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
sectionEnd
section "Links"
; create the start menu directory & shortcuts
CreateDirectory $SMPROGRAMS\DTE
SetOutPath "$INSTDIR"
CreateShortCut "$SMPROGRAMS\DTE\AltControl.lnk"
"$INSTDIR\%ENGINE%\%DERIV%\alt_control.exe"
; Broadcast to all processes that they need to update their environment
; http://forums.winamp.com/showthread.php?t=118501
SendMessage ${HWND_BROADCAST}
${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000
sectionEnd
After you run the installer, then attempt to run the start menu shortcut AltControl.lnk, you get a Windows missing shortcut error. Specifically: "Windows is searching for alt_control.exe. To locate the file yourself, click Browse."
If the environment variables already exist when you perform the installation, then the link works. Even weirder, if you click on the start menu shortcut properties and make some trivial change (like add and remove a space in the comment field) then click apply, Windows seems to regenerate the AltControl.lnk file (I know because the .lnk file increases in size even though no functional change was made through the dialog!?) and it works! So it seems like NSIS or some background Windows process in charge of generating/resolving .lnk files is not picking up on the newly created environment variables during the installation process. I've scoured the web and everything seems to indicate that the SendMessage I'm using should force everything to be aware of the newly created env variables. Thanks in advance to whoever can solve this mystery. You can use the included installer.nsi script to replicate my situation. Also note that it exhibits this behavior in multiple environments (XP, Vista, 7, with/without admin, etc.).
Most applications do not handle that message broadcast, it is mostly just for explorer.exe.
You can update the variables directly in your installer process and that will also be inherited by child processes:
System::Call 'Kernel32::SetEnvironmentVariable(t "ENGINE", t "v8")'
I'm using c#, .net 4, WIX 3.5, Windows Vista.
I have made my application compatible with RestartManager by p/invoking the RegisterApplicationRestart method and by handling the WM_QUERYENDSESSION and WM_ENDSESSION window messages (I return new IntPtr(1);).
If I try to update my application manually, then everything works as it should:
Launch application;
Launch msi file containing new app version;
During the installation/update, I'm prompted to close the running application;
Upon continuing the running app is closed, install completes, and the app is restarted;
If I try to update my application from the application itself, then I run into problems:
1) Launch application;
2) Download the new msi file;
3) Launch msi file with:
using (System.Diagnostics.Process p = new System.Diagnostics.Process())
{
p.StartInfo.UseShellExecute = false;
p.StartInfo.FileName = "msiexec";
p.StartInfo.Arguments = "/i \"" + downloadPath + "\" /passive";
p.StartInfo.UserName = "Administrator";
p.StartInfo.Password = securePassword;
p.Start();
}
4) Because I'm using passive mode, the application is closed automatically;
5) After the installation, my application is not restarted and under Event Viewer I have an
Event 10007 - Application or service 'MyApp' could not be restarted.
I have tried:
Not to use passive mode for msiexec;
Launch msiexec via cmd.exe (cmd.exe /C "msiexec /i ....") - in the hopes that launching msiexec from another process would solve the problem;
Wait for 60+ seconds before launching the msi update (shouldn't be relevant in my scenario, but MSDN documentation has something about it...)
But none of the above has worked (always the same result).
Having to launch the setup with elevated permissions might have something to do with the issue, because during the manual update I get a warning in the Event Viewer - Application MyApp (pid 3220) cannot be restarted - Application SID does not match Conductor SID.
Despite this, restarting the app still works. Googleing the warning yields no good/specific results, only that this warning is probably caused by running the msi in an elevated prompt.
How do I fix (or workaround) this issue, so that I can update my application from the application itself and restart my application afterwards?
Edit - extra testing:
There doesn't seem to be a need to respond to WM_QUERYENDSESSION and WM_ENDSESSION messages, because application restart during a manual upgrade works without them, so we can rule them out;
If I don't provide administrator credentials to the application initiated upgrade and instead I type them in during the upgrade, then app restarting works;
If I run an elevated command prompt and initiate an application upgrade from there (manually), then app restarting still works;
In order for application upgrade to work at all under Standard user accounts (so far I tested under an Administrator account with UAC), then I also have to set p.StartInfo.LoadUserProfile = true;. Otherwise nothing happens. (application restart still doesn't work though);
I tried all other process StartInfo parameters that I could set - WorkingDirectory, Redirect, Verb
(= "runas") - no change in results;
I installed Vista SP2 onto the virtual machine that I have been testing on (so far ran SP1), but no change;
I performed an "automatic" application upgrade with verbose logging. In the end there was an error message - RESTART MANAGER: Failed while restarting applications. Error: 352. That error code is very generic (http://msdn.microsoft.com/cs-cz/library/aa373665), inorder to get more detailed info I would have to write my own installer that would call RmGetList after the error, then I might get more details (this though is something I'm not willing to do);
Edit 2 - msi log file:
http://mommi.planet.ee/muu/log.txt
Assuming that the manual process indeed works without any problem it seems that your need for Administrator privileges in combination with the "updating itself" leads to these problems. I see the following options:
create a batch file to execute the update
When you want to update call this batch file (with elevated privileges), make the app close itself... the batch file should wait some seconds, then check whether the app is still running (and close it in case) and then run the commandline you need to run msiexec - don't restart the app from within msiexec but after a successfull run of msiexec from the batch file.
create a batch file which is always used to start the app
When the time comes to update you just end the app. Either the batch file check for an available update and applies it, starting the app after successfull update OR the app set some environment variable which is then accordingly processed by the rest of the batch file.