I have an sideloaded UWP application where I want to do automatic updates via a UNC path.
My application is able to download the updates by itself into C:\Users\<username>\AppData\Roaming\somerandomfolder
However it seems, that the automatic update mechanism does not handle system variables:
When entering %appdata%\somerandomfolder, it says: "Path has to begin with https:// or \\"
When entering C:\%appdata%\somerandomfolder (which leads to the same path as above when entered in Explorer), VisualStudio accepts the path, however instead of using the correct path, it creates a folder %appdata% at C:\
Is there a way to enter an update path for sideload updates without knowing the exact username?
Thanks in advance
Related
i have created extension by using crossrider they gave me xpi & crx file which i extracted and want to install manually by copying data to the browser's extension path.
I've read & tried many posts regarding this but they are not helpful because i think some posts are old & not able to find target paths & registry.
like in many posts they say create the following key in the registry here
32-bit Windows: HKEY_LOCAL_MACHINE\Software\Google\Chrome\Extensions
but i couldn't find that on my windows registry & i am using 32bit.
i want something like i copy my extension data to the browser's extension directory & inject some registry value thats all. if it possible then How?
For firefox just add the xpi or unpacked folder to the profile folder. No need for registry so its cross platform.
It can't be automatic as spyware would be all over that. After placing xpi in the extensions folder of the profile, on next startup of Firefox it will prompt saying it found an unauthorized by user add-on, and gives user a chance to enable it, or keep it disabled.
If you want to do it without startup, just launch the file path to the xpi or unpacked folder (if unpacked folder doesnt work, then point it to the install.rdf) in the browser, user will be prompted if they want to install.
There are some registry options though: Install Firefox extension using Windows registry
In Chrome, it's no longer possible to add an extension programmatically on Windows unless the extension is actually published in the Store.
This is for security reasons: previous registry-based (and otherwise) methods were open to malware abuse.
If your extension is published in the store, you can add it semi-automatically via registry. The user will still be asked whether to enable it on the next load.
You can also install extensions silently using Enterprise policy (only if the machine is part of a Windows domain and you have admin rights on the domain policy), on other OSes, or load it unpacked for testing with the --load-extension command line switch (will not persist after Chrome is restarted).
In Chrome go to
chrome://extensions
Enable Developer Mode at the top and click on the button to load an extracted extension.
Where is in the registry the path executed when I run the "notepad" command in windows "Start->run command" interface? I want to change it for notepad++ (it is required so, although could look not really good)
If you are like me you use windows run command all the time. I hate using the mouse to point and click a shortcut on the start menu. WIN-R are probably the two most over used keys on my keyboard. After thinking about if awhile I hunted down how the run command works. It turns out that it makes a call to ShellExecute, which I guess is not too surprising. The next thing I wanted to find out was exactly how the commands are resolved. The following is an ordered list of how they are resolved ([1]):
The current working directory
The Windows directory (no subdirectories are searched)
The Windows\System32 directory
Directories listed in the PATH environment variable
The App Paths registry key
Naturally the next thing I wanted to do was customize existing commands or add new commands so I do not have to type as much (standard lazy approach). After examining my options which were to put the executable in one of those paths (since it only locates executables and not shortcuts), modify the path environment variable or add a key to App Paths. The App Paths option seems to be the easiest and most flexible to me. Here is a layout of what you need to do to add an App Paths entry ([1]):
HKEY_LOCAL_MACHINE-->
SOFTWARE-->
Microsoft-->
Windows-->
CurrentVersion==>
App Paths-->
file.exe-->
(Default) = The fully-qualified path and file name
Path = A semicolon-separated list of directories
DropTarget = {CLSID}
Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. I cannot guarantee that problems resulting from modifications to the registry can be solved. Use the information provided at your own risk.
The minimum needed to add a new entry is to add the key file.exe where file is the string you want to type into the run command and to add the Default entry which is the fully-qualified path to the file you want to execute. Note that even it the file you are going to reference isn't an exe file you still need to put the .exe on the key. Here is a sample registry file that I created to add a shorter keyword for Internet Explorer:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\ie.exe] #="C:\Program Files\Internet Explorer\iexplore.exe"
After entering that entry into the registry I can simply type “ie” at
the run command to open internet explorer.
Here is a list of some common commands I use at the run command:
cmd – Command prompt winword – Microsoft Word excel – Microsoft Excel
outlook – Microsoft Outlook iexplore – Internet Explorer firefox –
Mozilla Firefox notepad – Notepad compmgmt.msc – Computer Management
Console control appwiz.cpl – Add/Remove programs dialog mstsc –
Microsoft Terminal Service Client regedit – Registry Editor
…
If there is some program that I find myself using all the time I figure out what the run command is for it and if there is not a short easy one I add one to my App Paths as described above. Does anyone else have some other common run commands they use?
We are trying to lock down a Terminal Server, and want to remove a commercial package's ability to accept UNC file paths, ie. paths in the app can then only be entered using the windows drive letters.
Is there any way to do this in Windows?
Can we disallow UNC paths for just the app?
Can we disallow UNC paths for the entire Terminal Server session?
The intention is to allow the application to only write to certain directories (as mapped in the Terminal Server session). The aim is to prevent the output of files to directories that the users have access to, but are not mapped in the Terminal Server session.
Look in the GPO under User Configuration>Administrative Templates>Start Menu and Task Bar>Remove Run menu from Start Menu (enabled or disabled?).
This prevents the user from entering in a unc path in IE address bar if enabled
According to windowsitpro.com,
You must edit the NoRun value (of type
DWORD) in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
or
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
registry subkey.
http://windowsitpro.com/Articles/Print.cfm?ArticleID=25421
But as Richard said, this is more of a serverfault.com question.
I am working on a Windows application which needs to be able to update itself. When a button is pressed it starts the installer and then the parent application exits. At some point during the installer, the installer attempts to rename the directory that the parent application was running from and fails with "Access Denied" If you run the installer from the desktop it works.
I am using CreateProcess to start the installer, is there some way of using this or another API to create the installer completely independantly from the parent application so that it doesn't retain some attachment to the directory.
I'm not convinced that launching the installer separately will solve your issue. It sounds more like a permissions problem that you might be able to solve using ACL manipulation. If the app doesn't already have permissions to mess with that folder, you might be able to write a custom action to remedy the problem by adding the necessary permissions to your process.
Another way of doing this is to make sure that the directory deletion is happening within a custom action that you control (as in, you own/maintain the code that performs the deletion, rather than rely on MsiExec to do it for you). Then, set that custom action to run in the System context so that it will have the same permissions as a service. That should provide your installer with sufficient rights to remove the folder.
You should use the normal update system within the windows installer.
your access denied message appears because file/directory is in use.
renaming directories isn't also not a good idea.
what happened if the user clicks "repair" or "uninstall" ?
you can start the msi with shellexec. after that terminate you app immediately.
you should check that in the msi that your app is NOT running anymore.
do the update. if a file is in use the installer automatically wants to reboot to replace the stuff.
CreateProcess should work if you are passing it the right parameters. Don't reference the parent process in any way and set most things to NULL. If that doesn't work, then you can try WinExec().
I am calling CreateFile() to create a file in the Program Data directory. I'm using SHGetSpecialFolderPath() to get the dir name.
I have a user with Vista for whom CreateFile() is returning error 5 (Access Denied). It would help if I knew where CreateFile() was actually attempting to create the file so we can check his folder permissions. The problem with Vista (UAC) is, it's not attempting to create the file in the directory I passed in. It could also be in a VirtualStore directory. An added source of confusion is this user is German and although SHGetSpecialFolderPath() is returning "C:\Program Data\blah blah" as the path, I don't think that's actually where the path is. I think German Vista uses the German word for "Program Data". I would like to be able to tell the user "This is the exact path where we are trying to create the file. Check your permissions on this folder."
I know you can get the a path from an open file handle, but in this case the CreateFile() is failing so I don't have an open handle. How can I get Vista to tell me the actual path where it's attempting to create the file?
Fire up Process Monitor and watch what it does:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
If with UAC the paths used are not the ones you want, then the redirection is in effect.
To make sure that redirection does not occur, add a manifest to your application which indicates to Vista that your application is properly coded and aware of access restrictions (i.e., you don't write to e.g., HKLM or the programs folder if your app doesn't need admin privileges to run).
But your application should be able to write to the APPDATA folder (if that's what you really use).
Make sure you're using CSIDL_APPDATA and not CSIDL_COMMON_APPDATA (the latter one being accessible only with admin privileges).
To find the real path (the one you would expect) tell the user to type %APPDATA% into the explorer bar (or hit Windows+R, then type %APPDATA%, enter). This will open the explorer on that folder.
My understanding is that ProgramData is used by Vista to write files that were attempting to be written inside C:\Program Files, but failed, since unless you are running the app as Admin you can't write inside program files. Maybe you should try saving your files to the AppData folder under the current user.