I see that there are way to Get Get-AppxPackage or Remove Remove-AppxPackage UWP app from windows 10 using PowerShell.
I am wondering if there is a way to reset a UWP app? I require it for automated testing, I would rather reset the UWP app than uninstall and install again, as that would slow down the testing.
If you're looking to clear your package's ApplicationData then you want
appdata = Windows.Management.Core.ApplicationDataManager.CreateForPackageFamily(pkgfamilyname)
appdata.ClearAsync()
See MSDN for ApplicationDataManager.CreateForPackageFamily() and .ClearAsync()
Powershell has no 'await' affordance last time I looked (though it's been a while) so not so viable. If you're looking to muck with applicationdata you may find APPDATA.EXE handy. You can probably guess why I wrote it... :P For instance
APPDATA.EXE Clear foo.bar_1234567890abc
If you're looking to reset a package to its initially installed state, then no, there is no API other than uninstall + install
Remove-AppxPackage foo.bar_1.2.3.4_x86__1234567890abc
Add-AppxPackage foobar.msix
Settings' Reset option for an installed package essentially does that just slightly more efficiently. You're still going thru the full deregister and uninstall the package and then install and register it for the user so it may not be instantaneous. But that's the only way to truly reset a package to its initial state. Windows has various forms of user data associated with a package (ApplicationData, IndexDB, more) as well as system state cribbed and wired up when a package is installed for a user (what is the package, where's it live, that the user has it, that it's status is not tampered or otherwise unhealthy, more). The only way to truly 'reset' that to the initial state is a full remove then add.
If you just need to wipe appdata then .ClearAsync is the ticket.
I am not aware of any command that would do that for you (except for the UI available in Settings app). However, you may write a PowerShell script that would clear up the application data files in the app's folder (this is not an official solution, but seems to work based on my trials).
Go to
C:\Users\{your_username}\AppData\Local\Packages\
And find your app's folder there. There are several folders containing the application state.
The nuclear option is to just delete all the folders. Then the app will crash once on startup, then the system will automatically reset it and restore the folders.
The less invasive option I have now tried seems to be to keep the folders and just delete their content, except for the AC folder, which seems to be system protected. When I tried this with my app, it launched successfully without crashing and system recreated the state files anew on its own.
The rest of application files lives in C:\Program Files\WindowsApps, but those are just application DLLs and content files and are read-only, so they should not affect the app state at all.
You may want to perform additional deletion if you use a shared publisher folder.
For windows 10 build 2004+ there seems to be a powershell command Reset-AppxPackage now.
UPDATE
My mistake, it is available from version 20175 onward. So, should be available in 20H2.
Related
I'm writing an app for macOS (12.1 locally) in Xcode 13.2.1. I need screenshot access, and it seems like the easiest way to get permission for that (in macOS 11 and later) is to use CGRequestScreenCaptureAccess, and to check eligibility using CGPreflightScreenCaptureAccess:
https://stackoverflow.com/a/65423834/444912
My code essentially looks like this:
let hasScreenAccess = CGPreflightScreenCaptureAccess();
if (!hasScreenAccess) {
CGRequestScreenCaptureAccess()
}
When I run a fresh build, a modal appears as expected:
and I'm able to see my app appear in System Preferences, also as expected:
Enabling my app's permissions prompts me to quit my app and restart it. This restarts my production copy of my app, from the app store. However, if I quit that and re-run the same build in XCode, my build is still not granted permission to record the screen (even though it appears as enabled in System Preferences). How do I allow my app to have permissions to record my screen locally?
We had a similar issue after renaming one of our apps which made use of the /usr/sbin/screencapture command line tool. The security prompt appeared every time a screen capture was triggered, no matter the activation status in System Preferences.
During development, the tccutil reset ScreenCapture {bundle identifier} command helped keep the permissions clean for subsequent testing.
I solved this in the process of writing this question, so I figured I'd share my answer. If I delete the copy of my app from my Applications folder, things seem to work. I assume that there is some sort of "claiming" process that goes.
It seems to work if I rename the copy of the app in my Applications folder, delete the screen recording in System Preferences, and then run my fresh build from Xcode.
In System Preferences, it can be the production copy of your app. You may need to replace it with your debug build app.
Delete it from System Preferences.
Locate your debug build app in Finder and drag & drop it to System Preferences.
Your debug build app must be given the permission.
I have installed the relatively fresh Visual Studio 2022 on a Windows installation. The work I do often requires administrative privileges (local IIS). To do this I have two users, one 'normal' account that is logged in to Windows and one administrator account. When starting VS2022 with the administrator account, an error keeps coming. It happens especially during debugging and it reads as follows:
Microsoft Edge can't read and write to its data directory:
C:\Users\<administrator_user>\AppData\Local\Temp\VSWebView2Cache\<guid>\EBWebView
What appears to happen is that Microsoft Edge WebView2 (msedgewebview2.exe) is running as the user that is logged in to Windows, while trying to write temporary files for the administrator user where it does not (and should not) have write or read access.
Here we can see the process details that says the application user is the logged in user and not the administrator:
Does anyone know how to fix this issue?
The error happen even when I run debugging on a .net 5 console application. In that particular situation I don't see why it needs to run anything in a WebView instance, but apparently some background process is running something anyway. Is this something that can be turned off?
My best solution so far is to create a shared folder.
I decided to make C:\Users\<administrator_user>\AppData\Local\Temp\VSWebView2Cache\ shared. The "VS" prefix indicates that this is a Visual Studio-specific folder, and I think it is acceptable that my normal user can have access to that folder as it seems to contain temporary Visual Studio files.
To do so I logged in to Windows with the administrator account.
I navigated to the folder and made it a shared folder. I added my no-admin user with "Read/Write" privileges.
I then tested by logging out of the admin account and into my no-admin account. There I first tried the full path in File Explorer and was granted access to the folder. I then tested with VS2022 and during debugging no error box appeared and files were generated in the folder.
If anyone finds a better approach, I'd really like to hear about it. Also if you have knowledge to why this approach is either good or bad, that would be highly appreciated as well.
I only had to create the folder "VSWebView2Cache" with my normal Windows account and after that it worked.
Recently, I was assigned the task to create a deployment package for an application which btw, I'm totally new at. So far, so good.. Now there is a requirement to extract files from a zip file which will be bundled with the setup file. So, I had to write custom actions in the 'Commit' section of the Installer class. I added the Installer class in a new project of type 'Class Library' under the same solution. I wrote the code after 'base.Commit(savedState)'.
I tried showing MessageBox at the event entry point, used Debugger.Launch(), Debugger.Break() but somehow, no matter what I do, it seems that the custom action is not willing to be hit at all and the application just installs itself. I searched a lot of sites and blogs but no help so far.
I've assigned my installer class (SampleApp.exe, in my case) to all the Custom Action's modes (Install, Commit, Rollback and Uninstall) in the Deployment project. Any help.
P.S. I'm using a Visual Studio 2010 setup project.
Thanks, in advance!
You should probably be trying a class library Dll, not an executable (which is typically for something like a service).
You don't need it all the nodes if all you're doing is calling at Commit. And why Commit? Install is just the same in most cases.
If you're not seeing a MessageBox then probably your CA isn't being called, and that may because it's not a class library. Note that your CA is not running in the interactive user context - it's being called from an msiexec process running with the system account, so you must be very explicit about (say) the path to the zip file, and any user profile folders will probably fail because the system account doesn't really have them.
What files are these and where are they going on disk? If they are user profile files you can install the zip files to a per machine location and then have the application itself unzip the files to the desired location on first launch. Unzipping from within your setup is not good practice - it is error prone and bad design.
Using the application allows proper exception handling and interactivity (the user can be informed if something goes wrong). Set some registry flags in HKCU when you have completed the unzipping so it doesn't happen more than once, and perform the unzip once per user.
I have an MSI package I maintain with Installshield 2012 Pro.
The package was created a few years again and requires periodic maintenance as new versions of the application is installs are released by our development team. This MSI has been used in many locations, on many machines without issue.
At one customer location, they've install about 20 copies of the application on 20 machines. Each machine is built exactly the same.
Periodically, for an unknown reason registry entries relating to that application go missing. Not all of them, a select one or two... the same entries always go missing.
We so far have failed to track the exact root cause, however one of our support engineers noticed the MSI repair dialogue appearing when they opened the application shortcut. Following this, the registry entries went missing.
On each instance of the registry entries going missing we have removed the MSI from the c:\Windows\Installer directory. On machines we've made this change too, the registry changes so far have not disappeared again.
This leads me to think the MSI is somehow removing the selected registry entries during the repair, but I don't understand how.
There are at least 50 registry entries under the same key as the entries that get removed. (these are created by the application not the installer)
The MSI package doesn't insert any keys at all during install
There are no custom actions at all
I only have one key file set in the whole MSI, and this is for a component installed in Windows\system32
None of the shortcuts are 'Advertised'
There appears to be a clear link between removing the MSI from the Installer directory and no further occurrences, but I fail to see what in my MSI could cause specific registry keys to disappear.
I realize the exact reason this this is subjective to my MSI or the customers systems, so as generally as possible I ask:
Why would Windows launch the MSI repair function, considering the above
Can an MSI alter the registry, considering the above
Is there anyway post installation of an MSI to disable the auto repair function for this MSI?
How should I alter the MSI to ensure auto repair doesn't occur?
Thanks
Start by proving whether the auto repair is related to your product. Check the application event logs for the component id that caused Windows Installer to kick off the auto repair. Then, if it's part of your installer, figure out why.
It seems unlikely that your MSI would alter the registry. Although you do not specifically say there are no RemoveRegistry table entries, it's hard to imagine any snuck in accidentally.
There are only bad ways to disable auto repair (some global, some involving not registering your installer). Avoid them.
First figure out what's wrong. Then figure out how to fix it. For instance if in step 1 you determine the component triggering auto repair is part of your install, perhaps set the logging policy on a machine where this occurs so you can get a verbose MSI log.
I have a setup project with InstallShield 2010. I'm deploying a configuration file during installation. However, when uninstalled, InstallShield decides to delete it (which is normal).
The question is, is there a way to keep the file on the hard disk even after the application in uninstalled? I don't want to reconfigure the application every time the user uninstalls/installs.
Edit: I'm using MSI project.
You don't say what project type you are using. Either way, put the config file in it's own component. For MSI projects, set the Permanent attribute to true. For InstallScript projects, set the Uninstall attribute to false.