locked
Vista Compatibility Questions RRS feed

  • Question

  • I am using Visual Studio 2008 Pro. I am developing on a Windows XP computer.

    I am attempting to make my Windows XP program compatible with Windows Vista. I have read through a ton of help files on this subject. I see quite a bit of helpful information but I can not find a good help file on sample source code. I am not sure where to start. I have several question if anyone can help I would appreciate it.

    First question is on the Special Folders and Vista Compatibility…

    I have read about three different ways to point to a special folder when loading or saving a file. Let’s say for an example the user loads a text file into the Editor in my program. What folder should I load and save this text file to? Will the following code place it in the correct folder?

    Dim AppDataFolder As String = _ Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) _
            AppDataFolder = AppDataFolder & "\MyCompany\MyAppName"
    
    SaveFileDialog1.InitialDirectory = AppDataFolder
            SaveFileDialog1.Filter = "txt files (*.txt)|*.txt|All files (*.*)|*.*"
            SaveFileDialog1.FilterIndex = 2
            SaveFileDialog1.FileName = “”
            TextToSave = “Sample Text”
    Try
                If SaveFileDialog1.ShowDialog() = DialogResult.OK Then
                    myFile = SaveFileDialog1.FileName
                    My.Computer.FileSystem.WriteAllText(myFile, TextToSave, False)
                End If
    
            Catch ex As IOException
                MsgBox("Error: " & ex.Message)
            Catch ex As SecurityException
                MsgBox("Error: " & ex.Message)
            Catch ex As Exception
                MsgBox("Error: " & ex.Message)
    End Try
    

    To make this software compatible with Vista, can I still use the SpecialFolders or do I need to convert this to the CSIDL constants and use a call to the API to get these folders?

    Second question is how do I implement the UAC on all of this? Is this all handled by the application manifest during installation or does my program have to check this before the user reads or writes the file?

     If I have to do this in my program where can I find sample code to show me how to do it?

    I may be totally misuderstanding these help files but after reading them several times I am still not sure where to start, which folders I should use for “All Users” or “Single User” and how to implement all of this.

    Any help you can give me or even pointing me to sample code would be very much appreciated. Even information on some type of Microsoft training class or Webcast on this subject would be great.
     

    Tuesday, June 9, 2009 5:49 PM

Answers

  • OK, first things first: The CSIDL constants and the KNOWNFOLDERIDs are largely a native code thing, the .NET SpecialFolders class is a nice handy wrapper around these and, as long as you don't need the special folders that were annoyingly omitted from the .NET class, you can happily use SpecialFolders to access them. :)

    As far as UAC goes, if your application isn't designed to administer the OS then all you need do is include the manifest to run AsInvoker. Your application will never ask for Administrator rights, never need them and you can happily forget all about UAC. As long as your application behaves as a Standard User, you are good to go!

    Which leads us on to the last bit, which Special Folders should you be using. The two key ones are ApplicationData and LocalApplicationData. These are both per-user locations and thus the best place for storing user settings:

    Of the two, ApplicationData will "roam" with a user if they log onto multiple computers in a domain environment, so it should only be used for small settings than should persist regardless of which computer the user is using, it's also important to ensure no machine-specific settings (such as hard coded paths) get stored here or you'll cause problems. LocalApplicationData is similar but is specific to a specific user on a specific machine, so you don't need to worry so much about the size of what gets preserved there. If you are in doubt about whether to use ApplicationData or LocalApplicationData, always go for LocalApplicationData it'll cause less problems in the long run.

    CommonApplicationData, which you used above, is a shared location so anything preserved there applies to all users of the machine equally. Generally speaking this should only be used to allow Administrators to pre-configure a bunch of settings that apply to all users that won't change under normal circumstances. If you really need to be able to share config data between all users and allow any of them to change it, then you can configure appropriate ACLs on a folder under CommonApplicationData, but you have to be prepared for the fact that can cause a lot of issues with users having their configuration accidently broken by someone else and it's generally best avoided.

    If you don't have access to a Vista machine to test on, a good compromise is to create a Standard user account under XP and test it there. Anything that breaks in that situation will likely break for all users on Vista. If it works fine as a Standard User on XP, it's almost certain to behave correctly under Vista.
    • Edited by AndyCadley Tuesday, June 9, 2009 7:14 PM
    • Marked as answer by StevenC1976 Tuesday, June 9, 2009 9:14 PM
    Tuesday, June 9, 2009 7:14 PM

All replies

  • OK, first things first: The CSIDL constants and the KNOWNFOLDERIDs are largely a native code thing, the .NET SpecialFolders class is a nice handy wrapper around these and, as long as you don't need the special folders that were annoyingly omitted from the .NET class, you can happily use SpecialFolders to access them. :)

    As far as UAC goes, if your application isn't designed to administer the OS then all you need do is include the manifest to run AsInvoker. Your application will never ask for Administrator rights, never need them and you can happily forget all about UAC. As long as your application behaves as a Standard User, you are good to go!

    Which leads us on to the last bit, which Special Folders should you be using. The two key ones are ApplicationData and LocalApplicationData. These are both per-user locations and thus the best place for storing user settings:

    Of the two, ApplicationData will "roam" with a user if they log onto multiple computers in a domain environment, so it should only be used for small settings than should persist regardless of which computer the user is using, it's also important to ensure no machine-specific settings (such as hard coded paths) get stored here or you'll cause problems. LocalApplicationData is similar but is specific to a specific user on a specific machine, so you don't need to worry so much about the size of what gets preserved there. If you are in doubt about whether to use ApplicationData or LocalApplicationData, always go for LocalApplicationData it'll cause less problems in the long run.

    CommonApplicationData, which you used above, is a shared location so anything preserved there applies to all users of the machine equally. Generally speaking this should only be used to allow Administrators to pre-configure a bunch of settings that apply to all users that won't change under normal circumstances. If you really need to be able to share config data between all users and allow any of them to change it, then you can configure appropriate ACLs on a folder under CommonApplicationData, but you have to be prepared for the fact that can cause a lot of issues with users having their configuration accidently broken by someone else and it's generally best avoided.

    If you don't have access to a Vista machine to test on, a good compromise is to create a Standard user account under XP and test it there. Anything that breaks in that situation will likely break for all users on Vista. If it works fine as a Standard User on XP, it's almost certain to behave correctly under Vista.
    • Edited by AndyCadley Tuesday, June 9, 2009 7:14 PM
    • Marked as answer by StevenC1976 Tuesday, June 9, 2009 9:14 PM
    Tuesday, June 9, 2009 7:14 PM
  • Andy,

       Thank you so much for the great response! After hours and hours of searching and reading this is the best information I have gotten. I appreciate it very much.

    Tuesday, June 9, 2009 9:13 PM
  • No problem, happy to help. :)
    Wednesday, June 10, 2009 8:50 AM