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
As a part of deployment script I need to add flag "run as admin" for some app. I found where it is configured in registry, but I see that is not enough. For example, I have procexp64.exe in C:\; I'm adding string value C:\procexp64.exe with data ~ RUNASADMIN in registry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. After this I see the checkbox "Run as admin" in exe properties, but actually the app isn't running as admin!
Ok, I removed my registry modification and configured it manually as show on the pic. The registry value appears back with the same data at the same place. I traced with procmon the modification and found that dllhost does it - it adds only one registry modification and doesn't modify anything on file system. dllhosts's modification works, but my modification - not. What I'm doing wrong?
Seems like it is not enough to add reg value...
Registry virtualization was disabled, user has admin rights. Win Srv 2012 R2.
Possible duplicate of: How to set "Run this program as an administrator" programmatically
Make sure you choose HKLM or HKCU correcly
You can try
reg.exe Add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\procexp64.exe" /d "RUNASADMIN" /f
or
reg.exe Add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\procexp64.exe" /d "RUNASADMIN" /f
I have a program written in vb.net. After I build, I want to launch an interactive batch file that executes a psexec command remotely. How can I do that?
this is my post build event:
call "$(ProjectDir)ExecOnGw.bat"
And this is my batch that if it runs in a normal command prompt, execution is ok.
c:\Sysinternal\psexec.exe \\gateway "C:\Remotepath\mybatch.bat" -u mydomain\myuser -p ******
pause
This batch calls another batch on a remote machine that does something, then if I want to exit, I have to press a "q" and "Enter". In a normal command prompt, it works fine. But in a Visual Studio post build event it goes down.
Help me!
I've done this before using the start command. I created a simple pause.bat file to demonstrate:
#echo off
pause Press Any Key
exit
If I put this in the post build event, I see a console that just closes.
call pause.bat
If I use this instead, I get a second console window that takes my input before closing.
start "My Process" /D c:\batch /WAIT pause.bat
Here is info about our technical development environment :
Microsoft Visual Studio Enterprise 2019
.NET Core 3.1
Just to add to #dsway good answer, I used Visual Studio 2019’s macros so that I could keep the directory path as relative:
start "My Process" /D "$(SolutionDir)Scripts" /WAIT blahblah.bat
Right-click on the Project in question
A context menu will show up
Select the Properties option
Select “Build Events”
Click on “Edit Post-build…”
Enter the aforementioned command that I posted above, and tailor it to your needs before pressing OK.
I have a simple bat file which does the following:
#echo off
mkdir folder1
mkdir folder2
echo.>file1
move file1 folder1\file1
When I run this on Windows 8 it will often hang the shell and explorer.
Interestingly, turning on/off the echo does seem to effect the chance of running into the bug (echo off hits the bug more often it seems) but I can get the bug either way. Suggests a race condition of some kind.
Anyone have an idea why this hangs on Windows 8? It doesn't on Windows 7.
I've also tried this using powershell. It happens less often (had to do it about a hunderd times before I hit the problem) but still occurs.
Turns out the problem was a combo of antivirus and search indexer. Both touch all the files in the FS as soon as they're created. I also suspect that the test machine being a VM has something to do with it (it is likely a little underpowered).
tldr; turning off windows.search from services fixed things.
I compile ConTeXt out of NP++ with the following command in the Execution-Plugin:
cd $(CURRENT_DIRECTORY)
context.exe "filename.tex" --synctex=1
taskkill /im SumatraPDF.exe
C:\somedirectory\sumatra.bat "$(CURRENT_DIRECTORY)\filename.pdf"
This command compiles the context-file and opens it in the PDF-reader Sumatra. As you see, I close the reader ("taskkill") and restart it again with every compile.
But that is not necessary, Sumatra updates the pdf-file by its own. So how to change the command, such that the reader will be only started, if it is not already started?
Have you already tried to remove the line
taskkill /im SumatraPDF.exe
and call something like this (the reuse-instance operator should do this quite well)
C:\somedirectory\sumatra.bat "$(CURRENT_DIRECTORY)\filename.pdf" -reuse-instance
at least this works for my current LaTeX setup with a quite similiar method.
This is a tutorial i used to get my NP++ working with MikTex
https://tex.stackexchange.com/questions/43984/using-notepad-with-miktex-on-windows