Ever wondered what is being returned if a virtualized app in App-V 5.0 asks for its own path? I tested it with a simple C++ exe that I created for that particular case. It uses the GetModuleFileName API to get its own path on the system. When running the exe, the output is its path and the directory listing of the folder it’s located in.
I created an App-V 5.0 package with the exe twice in it, once in the VFS and once in the PVAD path (PVAD = c:\getPathOfExe):
– c:\getPathOfExe\getPathOfExe.exe (PVAD)
– c:\Program Files\getPathOfExe\getPathOfExe.exe (VFS)
There is nothing else in the App-V package than these 2 files.
So to finally test the behavior after having added and published the package, I opened a cmd.exe within its virtual environment and did run both of the exe files.
Running getPathOfExe.exe in PVAD:
Right after running the exe, you see the output of the exe’s path itself. Although it has been installed to c:\getpathofexe\, it knows that the real location is in c:\programdata\app-v\…
The next output is the directory listing of the folder it’s located in. It automatically merges with the local folder c:\getpathofexe\. C:\getpathofexe\hahahaha\ exists on my system, so it merges the folder absolutely correct. Additionally I created the folder “test” within the virtual environment which is also shown as it should.
Running getPathOfExe.exe in VFS:
The behavior is the same in PVAD and VFS. GetPathOfExe.exe recognizes that it’s located in c:\programdata\app-v\… and not in the VFS c:\program files\getPathofExe\.
In the App-V package I configured to merge c:\program files\getpathofexe\ with the local folder, that why you see the folder “hahaha” shown in the directory listing. “test” folder has been, like in the PVAD test before, manually created within the virtual environment. Directory listing works as expected.
What is the take away of the lesson? Files running in a virtual environment exactly know their “real” location.