I am developing windows app and i have side-loaded the app. For some debugging purpose i need to inspect the installation directory.
I looked for it in below directory but can't see it there.
C:\Program Files\WindowsApps
Where are the windows 10 apps installed on drive?
You can find your application data in the following path ..
C:\Users\Default\AppData\Local\Packages\(Your packageName)
The package name is usually somewhat like this "Microsoft.Windows.Cortana_cw5n1h2txyewy".. you will need to identify your package accordingly..
Related
I have an electron app. Pretty basic app. It doesn't use ffmpeg for anything it does play an mp3 chime from time to time. I build my app with electron-forge using squirrel format. I then sign it using the SafeNet Authentication app. It's always worked flawlessly.
It's been a couple months since I last released a version. Only thing that has changed is some html ui updates within my electron app and of course lots of Windows 10 updates.
My app builds fine using electron-forge, it installs and runs without issue. I then sign it like usual from the command line and SafeNet confirms it was signed. Right clicking on the file shows it has been signed by my organization. However, once I execute the signed app I get this error: "The code execution cannot proceed because ffmpeg.dll was not found. Reinstalling the program may fix this problem."
Here is what I have tried so far:
Building/Signing on a different windows 10 machine.
Uninstall/Reinstall SafeNet.
Running signed .exe on a different Windows 10 instance
Building/Signing with a cmd session ran as administrator
I am at a loss, why is it screaming about ffmpeg.dll which my app doesn't depend on? Why only after the .exe has been signed do I get this error?
OS: Windows 10
Electron v7.3.2
Electron-Forge/cli v6.0.0-beta.47
SafeNet x64 v10.3
I feel really stupid. I was trying sign the wrong .exe file. Electron-forge creates two output directories when building an app, a directory called "make" and a directory with the name of your app. I should have been signing the .exe in the make folder. The .exe in the app name folder is a stand alone .exe that doesn't have any of the supported .dll files built into it.
After run the
npx #electron-forge/cli import and `npm run make`
Inside the project folder path it creates out folder. Inside out, there are two folders make and electron..........
Go to make then 64x and then you can find .exe
Use that one. It will work without any issue.
According to the Windows installation rules, programs should be installed to
C:\Program Files (64-bit program / x86-64) or C:\Program Files (x86) (32-bit program / x86). The program is copied into a sub-sub-folder containing the vendor name and the program name.
But why doesn't Chocolatey install packages into C:\Program Files\<Vendor>\<Program>\?
10. Apps must install to the correct folders by default
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user
10.1 Your app must be installed in the Program Files folder by default
For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.
Source: Certification requirements for Windows desktop apps
Version: 10 (July 29, 2015)
It depends on your version of Chocolatey, it's settings and the packages themselves.
To start, see Tools vs Applications and Chocolatey's distinction (
https://github.com/chocolatey/chocolatey/wiki/ChocolateyFAQs at the
bottom).
If the package does not use a native installer (a tool), it depends on
if the package author has used the bin_root concept that is up and
coming in a future version.
For example, SysInternals will go to c:/sysinternals right now unless
you have a defined $env:chocolatey_bin_root variable. The concept in
the code will change as well as right now this requires it to be a
subfolder of the system drive and I don't see us developing the final
feature with that limitation.
If the package doesn't have that concept yet, one can always ask the
package author to incorporate it.
If the package uses a native installer (an application), one can use
installArgs to pass arguments to the native installer
(https://github.com/chocolatey/chocolatey/wiki/CommandsInstall) and
tell it the directory to install the application to. This does require
you to know what you need to pass to the native installer. If you want
your applications in a custom directory, there is an assumption that
you are already an advanced user so it is expected that you would know
what to pass the installer if you were doing a silent install.
Slightly paraphrased from: https://groups.google.com/forum/#!msg/chocolatey/uucAz8GxebA/HEPAKp69d90J
Also,
NOTICE: As of 0.9.8.24, Chocolatey's default install location is
C:\ProgramData\Chocolatey
This reduces the attack surface on a local installation of chocolatey
and limits who can make changes to the directory.
Source: https://github.com/chocolatey/chocolatey/wiki/DefaultChocolateyInstallReasoning
And from personal experience I can attest that that concept is an excellent line of defense (when properly configured, used and understood).
PS:
As you already added to your answer, technically the requirement is %ProgramFiles% and %ProgramFiles(x86)% environment variable(s where applicable).
For example, %ProgramFiles(x86)% could as well point to P:\Software\Programs\x86\ (instead of C:\Program Files (x86)\).
There is obviously a lot of legacy software (now (re-)packaged) that never used a <vendor> section in the path-name.
Hope this helps!
I have a program that I have developed for mac osx. When the program is run from within Qt creator, a log file and a config.cfg file are created in the myapp.app/Contents/MacOS folder, alongside the executable. This is the correct behaviour, the program needs these files.
When I deploy the app to run standalone (by linking the required libraries using macdeploymentqt tool) the app launches and runs correctly however the log and config.cfg file do not get written to the myapp.app/Contents/MacOS folder and so settings can't be read in.
Is there anyway to get around this? Has anyone encountered this before?
Mitch
osx will likely not allow you writing to your bundle location on installed apps, for security reasons and because it may conflict when multiple users are using your app.
To be cross platform, you could write instead to:
QStandardPaths::writableLocation(QStandardPaths::AppLocalDataLocation)
which resolves to
~/Library/Application Support/<APPNAME>
and
C:/Users/<USER>/AppData/Local/<APPNAME>
or equivalent on windows.
You're never supposed to write to the application bundle, whether on Mac or on Windows. Even on Windows, it will not work if your user isn't an administrator. This idea last made sense on Windows 95 - not even on Windows NT. Don't do it.
I'm looking for a command line arg that shows me what version(s) of vb are installed on my windows 7 dev machine.
Specifically I'm looking for VB6 information - if it's setup -what dll's are registered/etc
To what end? If you're interested in knowing from an installer point of view, about the only thing you can do is check the SYSTEM folder for the MSVBVM60.dll file (and possibly others depending on what parts of VB6 you've made use of).
But that file doesn't HAVE to be in SYSTEM32, it could be anywhere on the path, or in the app's folder itself.
I'm using some custom actions to install plugins into Firefox in an Installer project.
Quickest path to ground thus far has been to use VBScript.
Currently, I've been assuming the FireFox installation directory is "%PROGRAMFILES%/Mozilla Firefox". Obviously, this needs to change to cope with people doing non-standard installs.
So, the question is, how can I get an installation path of an application (known by name, GUID, whatever) using VBScript*?
*If its downright impossible, using C# is also acceptable (and seems to be answered in a few places) but that will require I redo some of the installation process currently implemented in VBScript; so its less desirable
There is an Install Directory string in the registry that will tell you where it's installed, however it's located in different places depending upon the version of Firefox is installed and the OS upon which it is installed. It will be in a key that looks like one of these:
Windows XP
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.5.3 (en-US)\Main
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.0.11 (en-US)\Main
HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Mozilla Firefox\3.0.5 (en-US)\Main
...
Windows 7 x64
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\3.5.3 (en-US)\Main
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\3.0.11 (en-US)\Main
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\3.0.5 (en-US)\Main
...