CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 8 of 8

Thread: Application.UserAppDataRegistry & Program Version

  1. #1
    Join Date
    Aug 2007
    Location
    Farnborough, Hants, UK
    Posts
    45

    Angry Application.UserAppDataRegistry & Program Version

    (Visual Studio 2005, .NET 2.0)

    While looking for a temporary alternative to storing user settings while my registry create subkey problem gets resolved, I stumbled across the UserAppDataRegistry property. Indeed, using this I can write out my user's settings without any problems - somehow .NET magically allows the necessary subkeys to be created.

    The thing is, it creates a registry tree of the form CompanyName/AppName/Version. While I'm perfectly happy with company name and app name - they make perfect sense - using the program version does *not* make sense. This means that every time you upgrade your application, it effectively forgets all its settings and the user has to reconfigure them (or you have to manually find the latest version they had stored and collect them from there to maintain them).

    This seems an incredibly stupid idea to me - anyone know why it was done this way? Is there some way to control it, to only use company name and app name? I think I can work around it but I shouldn't have to!

  2. #2
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,277

    Re: Application.UserAppDataRegistry & Program Version

    Perhaps a user would like to run different app versions side by side?

    Without versioning this wouldn't be possible.

    On the other hand, if you upgrade an application you can certainly copy over settings during the install process.

  3. #3
    Join Date
    Aug 2007
    Location
    Farnborough, Hants, UK
    Posts
    45

    Re: Application.UserAppDataRegistry & Program Version

    The versioning itself isn't the issue - it's the fact that settings are stored per version. Chances are, even if you wanted to run two versions side-by-side, I'd say it's 95% certain they would use the same settings for both. Even if you didn't for some unusual reason, there just seems no mechanism for porting across the old settings - it has to be done manually. Surely at the very least some way to automatically import older version settings would be useful?

  4. #4
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,277

    Re: Application.UserAppDataRegistry & Program Version

    Look at this another way. How could Microsoft possibly know what settings you are going to reuse as an application developer?

    Perhaps the values have the same name, but the range has been extended for the new version. Won't this break the old version?

    At any rate, the mechanism for retrieving the previous keys exists, look at the RegistryKey class.

  5. #5
    Join Date
    Aug 2007
    Location
    Farnborough, Hants, UK
    Posts
    45

    Re: Application.UserAppDataRegistry & Program Version

    >Look at this another way. How could Microsoft possibly know
    >what settings you are going to reuse as an application developer?

    They don't need to know - our apps know what they do and don't use.

    >Perhaps the values have the same name, but the range has been
    >extended for the new version. Won't this break the old version?

    Yes, possibly; but then that would be bad app design, to assume that whatever they read in is in an acceptable format / range. A good app will be able to cope with out-of-range values by using the nearest most appropriate value, don't you think?

    >At any rate, the mechanism for retrieving the previous keys exists,
    >look at the RegistryKey class.

    Unless I missed it, the only way we can do it is to enumerate the subkeys of our app name's key and determine the latest version (if any) stored, then read them from there. I was hoping for some Registry(Key) call that would automate that process. Obviously if your app has changed its name, or your company has changed its name, then this is not possible; but it seems a little bit of an oversight to just spawn a new key and force the developer to find the previous settings manually.

  6. #6
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,277

    Re: Application.UserAppDataRegistry & Program Version

    Quote Originally Posted by JTeagle
    >Look at this another way. How could Microsoft possibly know
    >what settings you are going to reuse as an application developer?

    They don't need to know - our apps know what they do and don't use.

    >Perhaps the values have the same name, but the range has been
    >extended for the new version. Won't this break the old version?

    Yes, possibly; but then that would be bad app design, to assume that whatever they read in is in an acceptable format / range. A good app will be able to cope with out-of-range values by using the nearest most appropriate value, don't you think?

    >At any rate, the mechanism for retrieving the previous keys exists,
    >look at the RegistryKey class.

    Unless I missed it, the only way we can do it is to enumerate the subkeys of our app name's key and determine the latest version (if any) stored, then read them from there. I was hoping for some Registry(Key) call that would automate that process. Obviously if your app has changed its name, or your company has changed its name, then this is not possible; but it seems a little bit of an oversight to just spawn a new key and force the developer to find the previous settings manually.
    You have your own opinions about what is good app design (and so do many other developers). You seem to be assuming that an app's code base will be rev'ed, but what about if the app is completely changed, and the only thing left intact is the application name? Do your comments regarding poor app design still hold true? MS needs to be a bit generic when it comes to supplying functionality.

    If the UserAppDataRegistry doesn't work for you because of your specialized needs, you are free to create your own implementation using the RegistryKey class that does what you need it to do.

  7. #7
    Join Date
    Aug 2007
    Location
    Farnborough, Hants, UK
    Posts
    45

    Re: Application.UserAppDataRegistry & Program Version

    Quote Originally Posted by Arjay
    If the UserAppDataRegistry doesn't work for you because of your specialized needs, you are free to create your own implementation using the RegistryKey class that does what you need it to do.
    No, I'm not, and it does not; that's the whole point. The only place we can write to the registry using RegistryKey is the place it defines - the version-specific key. If we try and write anywhere else, it fails. I even tried using that key just to get the branches created, and then went and tried to use the parent branch (the application key) to write values - but it failed.

    I can certainly understand having a version-specific key to allow side-by-side installations, as you suggested, but I cannot understand why they did not also allow us to be version-neutral; more specifically, I cannot understand why they did not allow us to write anywhere under our own application's key. We're locked into the .NET system of using the registry. I suspect that even if I tried a DLLImport to use RegSetValue(), I would be denied access. I'll have to ignore the registry and use a local config file instead.

  8. #8
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,277

    Re: Application.UserAppDataRegistry & Program Version

    Search google for "Lutz's Reflector" and use this tool to look at the .net source to UserAppDataRegistry. Perhaps this will tell you what permissions are required.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)