I suggest you ...

Registry functionality in the userconfig xml

The Registry functionality in the config xml should work more like it did in App-V 4.6, where the code is executed at launch every time in the users context no matter if it was HKLM or HKCU. If I want the registry setting applied in user, then user config.xml; if I want the registry setting applied using system context then put it in the machine config xml etc.

I,e, <Registry Enabled="true">
<Include>
<Key Path="\REGISTRY\USER\[{AppVCurrentUserSID}]\Software\myapp\somekey">
<Value Type="REG_SZ" Name="hello" Data="world"/>
</Key>
</Include>

in App-V 4.x this OSD edit would apply at launch every time, and the syntax was relative to the user context so we should do HKLM or HKCU

<REGISTRY>
<REGKEY HIVE="HKCU" KEY="Software\something" NOREDIR="FALSE">
<REGVALUE REGTYPE="REG_SZ" NAME="Database_Server">DB-01</REGVALUE>
</REGKEY>
</REGISTRY>

I recently had a need to make a change to an existing package that I was upgrading, and attempted to use the new Registry functionality in the config xml for my published (and updated) package and discovered this does not work anything like the old App-V 4.x way. Why is that? why couldn't it work the same way or similar?

This feature from appv 4.x was great for quickly changing something in an existing package, or over-riding a user cached preference, i.e. an ODBC DSN or License server name etc. We should do a quick change without having to re-package or update an existing package and go through all the steps and testing that involves.

There are many ways to skin a cat, of course. But this Registry feature/setting that exists in the config XML does not make any sense to me. Why would someone need to use it the way it is today, if it does not work like the Registry tag from AppV 4.x did?

p.s. I could be wrong in how this works but I tried and tried, and it just does not work the way I expect. I asked a question on the TechNet forums and was basically told it does not work the way it used to in App-v 4. and was given the advice to not even bother trying to use this feature to solve my problem.

4 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    BruceBruce shared this idea  ·   ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • BruceBruce commented  · 

        CLARIFICATION: I have thought about this some more, and ran a few more tests.

        It looks like this ability to add a registry value or key in the dynamic configuration xml file(s) applies to the package and not to the user cache. The previous version wrote their changes via the OSD file into the user cache.

        It would be super if something could be done to allow the administrator to choose where the registry statements we put into the dynamic configuration are going to go - the package or the cache. Similar to how we can execute user scripts as virtualized or not, for example.

      • BruceBruce commented  · 

        just a typo fix "in App-V 4.x this OSD edit would apply at launch every time, and the syntax was relative to the user context so we should do HKLM or HKCU" should read "in App-V 4.x this OSD edit would apply at launch every time, and the syntax was relative to the user context so we could do HKLM or HKCU"

        I have found that users did have in 4 (and do still in 5) access to make changes to HKLM values if those values were captured in the package.

      Feedback and Knowledge Base