By default, the installer for my product copies files to the Users\Username\AppData\local\MyProduct directory (though the user can change this during installation, of course).

I want to bundle some other files with product - documentation, sample spreadsheets (it includes an Excel add-in) etc. It doesn't seem appropriate to copy these additional files to AppData because it's a hidden folder that users shouldn't really muck about with.

I could, of course, create a new sub-folder in the user's Documents directory and stick the files in there but as I haven't asked their permission to do this it seems impolite.

So - any suggestions as to an easily accessible location to put these files in?

  • 1
    Why are you installing program files into AppData? They should go into the 'Program Files' structure. Commented Oct 14, 2013 at 17:41
  • Agreed, but it's a per-user application that in many cases will be running on shared servers so there is a need to isolate user setups. Commented Oct 14, 2013 at 17:46
  • Are the executables themselves shared between installs? If so, I'd put the exe files in Program Files, and let the app data handle personalized configuration files. Commented Oct 14, 2013 at 17:54

3 Answers 3


I see 3 choices:

  1. Plonk it on the Desktop & let the user move it wherever.
    It's simple, obvious, and only mildly annoying.
  2. Create a "Docs" folder inside the folder that has your executable.
    It's also simple and there's the reassurance that everything will be deleted when you uninstall.
  3. Put it in the Documents folder anyway.
    That's what everyone else does and in your case it actually makes sense to put them there.

I agree that Users\Username\AppData\local\MyProduct is not a very friendly location for files you want the user to access.

Whatever you do, you may wish to pop up a message telling the user what you've done.


Help and associated documents can be installed into the same path/path structure that you use for your executable files. If for no other reason, it makes it easier for your program to find them if you want to launch the help files from within your program.

To make it easier for end users to find your documents, make shortcuts in the program's start menu folder. But you'll want the docs to be reachable from within your program, because many Win8 users (and frankly, many users all together) either dont have a start menu (Win8), or dont know how to use anything other than a desktop icon to launch a program.

Sample files are more of a 'it depends' topic. It depends on what you are expecting people to do with the files. I usually put them into the same directory structure as the executables. But if sample files are meant to be edited and saved, you might want to put them in their own directory under My Documents.


Whatever you do DO NOT put them in AppData. Adobe does\did this for a long time (haven't looked in awhile but I'd assume they haven't wised up yet) and a huge AppData folder is a mess for system administrators to deal with. For example, if these documents add up to any size they will slow down roaming profiles to an excruciating pace. That is just one company and by now most shops have worked out a way to handle those particular files, if that became standard it would be impossible to manage.

I would say that the best way to handle this depends somewhat on whether or not these documents grow. If these are static files then place them in your Program Files folder. Then at some point during installation ask the user whether they would like the documentation placed in there documents, public documents or left alone. If they select an option then place a shortcut to the folder which has these in the appropriate location.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.