I have an application that hosts a remote object. For the client application to access this remote object; the dll with the remote server implemented, should be in the same directory where the executable of the server application resides. When I install this application the dll resides in a different directory and I manually paste the dll to the same directory where the server executable resides.
I do not want to do this every time. Is there a way to get around this problem? That is the application refer the dll from where it is available rather than demanding the dll to be in the same directory where the executable resides.
See http://www.informit.com/articles/article.aspx?p=30601&seqNum=6
Related
My build system, which uses meson, puts some files my application needs on AppDir under AppDir/usr/share/myapp/resources. The application needs both, read and write to those files when it is running. The files are in AppDir when I look at it, but when the .AppImage is generated, the standalone running executable cannot access those files. When integrating the application with the desktop, the application gets installed in ~/Applications, but it doesn't contain those files.
Here is a visualization of how it looks when the application is installed on the system without using AppImage (ninja install)
🗀 usr
🗀 share
🗀 myapp
🗀 resources
🖹 MainWindow.glade
🖹 dataCache.json
When I do DESTDIR=AppDir ninja install the structure ends like this
🗀 AppDir
🗀 usr
🗀 share
🗀 myapp
🗀 resources
🖹 MainWindow.glade
🖹 dataCache.json
When the application (MyApp.AppImage) is integrated into the user's desktop with AppImageLauncher, it only copies the AppImage into the Applications directory. There are no other folders or files.
Edit: I am using ./linuxdeploy-x86_64.AppImage --appdir AppDir to create the directory AppDir. Then I use DESTDIR=AppDir ninja install to install the app to AppDir, and then I use ./linuxdeploy-x86_64.AppImage --appdir AppDir --output appimage to create the AppImage
How would one go to access those files that were in AppDir once the app is bundled? Or how does one make the app integration copy those files to the Applications folder so that the application can have access to them while the application is running?
To resolve the AppImage mount point at runtime you can use the APPDIR environment variable. For example, if you want to resolve usr/share/icons/hicolor/myicon.png you need to use the following path $APPDIR/usr/share/icons/hicolor/myicon.png.
It's recommended that you modify the application to be able to resolve its resources depending on the binary location. As an alternative, you can use a custom environment variable to set up the path or a configuration file next to your main binary.
Regarding writing files inside the AppImage. This is not possible by design. An AppImage is a read-only SquashFS image that is mounted at runtime. Any application data should be written to $HOME/.config or $HOME/.local/share depending on whether it's a configuration data or other kind of data. The recommended workflow is to copy such data on the first run.
For more information about whether to copy your application data see https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
I run this code in powershell:
$AppVName = Get-AppvClientPackage <Package>
Start-AppvVirtualProcess -AppvClientObject $AppVName cmd.exe
then i write file with cmd command; the file is persisted on host filesystem. Is this normal behavior, i thought that virtual processes is run in some kind of "bubble" ?
How do i enable this bubble so that files written by virtual processes are not persisted?
This is one of the correct methods to run inside an app-v container.
Is the file that you're modifying/writing is in a path that is part of the original VFS structure of your app-v package, or are you saving it in another folder from the machine?
If the cmd.exe process is modifying files that are not present in the VFS folders from the app-v package it is normal for those files to persist on the machine.
You can check the VFS folder structure from app-v package by unzipping with 7-zip.
In the Microsoft documention the dll loading order is defined under the following link
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
If SafeDllSearchMode is disabled, the search order is as follows:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
I don't understand the difference between
directory from which the application loaded
current directory
Let's say the application is installed in %programfiles% and I have a shortcut on the desktop to start it.
In that scenario what is "The directory from which the application loaded."?
The current directory must be the dektop, right?
Any clarification is greatly appreciated.
I'm trying to generate coverage info with gcov. The configuration is a little tricky. I have some of the testing running from the same machine. Others are implemented in Matlab and access the executables on the test-machine remotely. When the test files are executed from the same machine, the .da files are generated. However, no .da files are created when I run Matlab test files which use the executables on the test machine remotely. I'm accessing the test machine remotely with root access, all the privileges seem to be correct. Any idea why .da file are not generated when the executables are accessed remotely?
Gcov generates .da files in the file system in which the executable resides. If your executable residing on the remote machine is the one enabled with coverage collection, you should look for .da files on the remote machine.
I have a jar in SERVER-A that reads from a file within SERVER-A. When I Remote SERVER-A (Remote Desktop Connection) and run it, it works fine.
But when I run the same Jar from a shared folder of SERVER-A via my local machine(not SERVER-A) it can not find the file.
I tried to print the current directory of the jar when its is running.
1. When running from Remote access to SERVER-A i got "E:\ISO_Tester", This is the correct path.
2. When running from Shared folder of SERVER-A i got "C:\Windows" which I think is from my local machine instead of SERVER-A.
How can I make the jar read from the server when its being accessed from shared folder?
P.S. I'm using environment variable for the file location to be read.
String propFile=System.getenv("OTHERS_HOME") + "\\conf\\FILE_TO_READ.txt";