As of the latest 9.18.5 OpenTAP version, the PackageCache folder has been moved to the C:\Users\XXXX\AppData\OpenTAP\PackageCache as compared to the 9.10.4 where it was located under C:\Program Files (x86)\Test Automation\PackageCache. Here, XXXX is the user account that was logged in to install OpenTAP.
Is there a way to install across all the users such that it can be accessed regardless of the windows account used to log in?
Thanks for the reply. Since our application is used by different users, there is a chance whereby the windows user logged in may be different from the user that installed OpenTAP. This results into the particular user not being able to access the packages cached/installed by other users.
Hence, we wanted to check the feasibility on such use cases. Do you have alternatives in mind?
Thanks for the suggestion. However, we are already doing that for shared set of packages - and that is not the problem here. Our problem is that when OpenTAP is installed - it installs the packages and caches them in the C:\Users\XxXx folder for that specific windows user. This results into the packages that were cached to not be accessible by other windows users.
I think there there is no way to do what you ask currently, but I also still don’t understand your usecase. Why is it necessary for the other users to access the packages through the cache and not the package repositories?
For our use case, the test stations that uses OpenTAP are used by multiple windows users. All of our applications are all user-wide settings, however OpenTAP restricts us to the specific user directories. Due to this, even though the packages are present in the user directory, we would still need to install from the central repository - requiring a network call. This deviates from the previous behaviour whereby the package cache was accessible by all users from the Test Automation folder.
Yes, it is a performance issue for us when the users need to install from the central directory. Hence, it is important for us to cache the installed packages.
Could you elaborate more on this approach/idea of having it as a setting? This will help us decide whether this could be helpful for us.
I think the environment variable would make more sense for us due to the following reasons - [1] we don’t distribute the engine settings to our test stations and [2] The engine settings wont be available during installation (assuming its a fresh installation), which means the default packages may still be cached in the default location. @rolf_madsen, what are your thoughts?
@brennen_direnzo Would it be possible to release this as a seed release for 9.18.5?
@antonio.quizon I don’t think we will be able to get this into 9.18, but @rolf_madsen has already implemented this fix with the environment variables and it can be available in 9.19: