Est AppData maintenant la "bonne" place à installer par l'utilisateur des applications spécifiques (modifier leurs propres données)?

Je suis probablement juste être très épaisse, ici, mais il n'est pas clair pour moi, où je suis censé pour installer les "nouveaux" spécifiques à l'utilisateur de programmes sur Windows 7 (et sans doute Vista aussi, bien que je n'ai pas cherché spécifiquement à ce scénario encore).

Sous Windows XP (à juste titre ou à tort) nous avons toujours installé nos programmes dans des dossiers sous 'Program Files " et accepté qu'ils seraient de type de disposition de tout le monde. De ce que je peux rassembler sous Windows 7, je suis censé installer mon logiciel en vertu de l'utilisateur AppData dossier (éventuellement AppData\Local\Monappli). Que fait une mesure de bon sens, mais le fait que ce dossier est "cachée" par défaut signifie que nous allons avoir du "plaisir" de parler de nos utilisateurs à travers le soutien des trucs.

Je veux installer notre logiciel de sorte qu'il est spécifique à l'utilisateur (les Utilisateurs bits de Windows 7 est parfaitement logique) mais je ne veux pas que l'utilisateur puisse y accéder si nécessaire. Notre programme comprend également un "data" sous-répertoire dont il a besoin pour écrire alors qu'il est en cours d'exécution (base de données intégrée), mais comme le programme est destiné à être mono-utilisateur/autonome, le dossier de données étant à l'intérieur d'un utilisateur-dossier spécifique ne va pas être un problème.

Mon problème est juste que toute la "dossier caché" de la AppData. Autant que j'ai parcouraient la MSDN, je ne peux pas savoir où je suis censé installer par l'utilisateur des programmes spécifiques. Prise dans un sens, il semble être quelque chose comme AppData\Local\Monappli, et une autre façon, il semble être tout aussi valide en vertu de l'utilisateur Mes Documents\Monappli équivalent.

Quiconque a un guide clair pour savoir où tout ça va? J'ai trouvé la MSDN docs à confusion. 🙂

  • Ah, je sais ce que tu veux dire. Mais j'ai un Mac-utilisateur depuis environ 4 ans maintenant et j'ai beaucoup apprécié la façon dont les choses comme cela sont fait "là-bas" - et j'ai l'impression que le plus de gens qui utilisent Windows correctement à l'avenir, plus nous aurons de chances de faire ce genre de choses " juste à travailler pour tout le monde dans l'avenir. De Plus, nous pouvons également être justement énervé avec Redmond la prochaine fois qu'ils font un balayage de changement arbitraire de quelque chose comme dossiers de demande (Gagner 8, anyone?)!!
InformationsquelleAutor robsoft | 2009-12-02
  1. 28

    Pas vraiment.

    Le répertoire qui sert de commun
    un référentiel spécifique à l'application
    les données pour le utilisateur itinérant.

    AppData est, de façon surprenante, pour les données d'application, pas pour l'installation (Cliquez une Fois/des applications Silverlight de côté). Vous pouvez et devez encore installer dans Program Files, il suffit de ne vous attendez pas à écrire dans ce dossier.

    Vous peut installez le logiciel dans AppData si vous souhaitez suivre un utilisateur dans un environnement Active Directory, ce qui arrive si vous le mettez dans AppData\Roaming (le SpecialFolder.ApplicationData emplacement).

    Vous pouvez aussi l'installer dans AppData si vous voulez que le logiciel à n'être accessible qu'à l'utilisateur qui l'installe. Cela peut être utile si, par exemple, vous avez plusieurs utilisateurs sur la même machine, qui veulent toutes exécuter différentes versions du logiciel dans un isolement complet.

    Si vous voulez paramètres s'appliquent uniquement sur l'ordinateur local, puis vous utilisez AppData\Local, qui est SpecialFolders.LocalApplicationData - ce qui va faire d'ANNONCE administrateurs très heureux que le profil itinérant taille ne sera pas soudainement sauter jusqu'à 50 mo ou quelle que soit la taille de votre logiciel.

    Si vous souhaitez créer des paramètres qui s'appliquent à tous les utilisateurs, alors vous êtes à la recherche à SpecialFolders.CommonApplicationData

    Vous devez vous rappeler de ne jamais compter sur le nom du répertoire - localisation des questions de dire que cela peut changer et l'emplacement ne change pas avec les versions de système d'exploitation de deux. Vous devriez être en utilisant la dossier spécial de l'énumération dans vos logiciels, ou l'équivalent dans votre installateur.

    Vous ne pourriez pas vous installer dans Program Files, mais l'utilisation AppData comme il est censé être utilisé, et de stocker votre base de données en y?

    • Merci, cela fait sens, même si elle nécessite des modifications au code de l'application elle-même, qui est une douleur. Le programme dispose également d'un fichier INI, qui, j'imagine, doit maintenant aller avec la base de données dans AppData\Local trop. Le seul problème avec l'installation dans Program Files est (je suppose) que l'utilisateur pourrait avoir besoin des privilèges d'administrateur lors de l'installation, alors que nous nous installions dans AppData\Local au cours de nos expériences, (je suis sûr), nous 's'est enfui avec elle'. Je ne pense que Microsoft ont défoncer ce un peu - par utilisateur, accessibles à tous les Fichiers de Programme aurait fait plus de sens.
    • Ooh, plus je suppose que maintenant nous aurions aussi à penser à ce qui arriverait si un autre utilisateur essaie d'exécuter le programme (via les Fichiers de Programme) sous leur propre compte - l'application aurait besoin de place qu'elle avait rien dans cet utilisateur AppData\Local dossier pour lui-même, et de générer un nouveau par utilisateur copie de la base de données et paramètres par défaut, etc. soupir, Il semble un peu de désordre pour moi!
    • Un fichier INI? Comment la vieille école êtes-vous 🙂 Et oui, les Fichiers de Programme n'a pas besoin des droits d'Administrateur pour installer, ce qui n'est pas une mauvaise chose, administrateurs de réseau n'aime pas les utilisateurs ayant la possibilité d'installer des bon gré mal gré 🙂 Sous windows il n'y a pas d'officiel "Par Utilisateur", installer, sauf si vous êtes en utilisant Sur une Fois, ce qui fait que, et utilise les Données de l'Application. Comme pour vérifier les bases de données manquantes, vous devriez faire de toute façon 😉
    • Heh - je suis très old school! Eh bien, j'ai commencé cet exercice vouloir faire les choses "correctement", et donc je ne. Je vais obtenir le programme d'installation pour avertir & vérifier les droits d'admin, je vais mettre une référence 'vide' de la base de données et le fichier de paramètres dans l'installation et ensuite à l'application de l'exécution si je découvre qu'ils ne sont pas présents dans AppData\Local, je vais les copier à travers. Dieu sait ce que tout cela va ressembler sous XP (il va être intéressant de découvrir quel AppData\Local alias sur l'ancienne plate-forme, etc). Merci pour vos conseils, blowdart. Vraiment apprécié.
    • J'ai oublié de dire - de toute évidence, le fichier de paramètres doit devenir un ensemble de clés de registre, trop. 🙂
    • Rappelez-vous de ne pas utiliser le chemin d'accès réel noms, utilisez le SpecialFolders énumération. Ensuite, vous n'avez pas à se soucier de ce qu'il ressemble sous chaque OS
    • C'était en fait très utile qui vous explique toutes les différences entre les dossiers. Maintenant, il prenait tout son sens.

    InformationsquelleAutor blowdart
  2. 16

    Windows 7 ajouté le FOLDERID_UserProgramFiles connue dossier et par défaut, il correspond à %LOCALAPPDATA%\Programs. Il est utilisé par MSI quand ALLUSERS=2 & MSIINSTALLPERUSER=1.

    Sur Vista et les versions antérieures n'est pas canonique par utilisateur dossier de l'application, mais seulement à l'aide de %LOCALAPPDATA% est assez commun. Malheureusement MSI va juste utiliser %ProgramFiles% sur ces systèmes.

    InformationsquelleAutor Anders
  3. 5

    Windows 7 structure de dossier est profondément inspiré sur Unix structure:

    /usr/-> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/-> C:\ProgramData\ -> global settings
/home/-> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user

    Windows a plus de dossier, à l'instar de Mes Documents pour des fichiers dont le contenu produit par l'utilisateur, AppData Local et de l'Itinérance (Unix qui gère habituellement avec NFS).

    Il est temps pour nous, les développeurs de commencer à utiliser ces structures. Nous devons séparer au moins des fichiers binaires qui n'ont pas besoin d'être répliquées, global et les paramètres de l'utilisateur.

    Lorsqu'un programme d'installation avec l'installation d'une application, cette configuration doit s'attendre à avoir la permission d'écriture sur les Fichiers de Programme. Une fois l'installation terminée, les Fichiers de Programme doit être accessible en écriture seulement pour les autres configurations visant à mettre à jour les binaires pour les autres versions.

    • Pour être juste, la hiérarchie du système de fichiers sous Unix est complètement obtus ainsi. Devrait données de l'utilisateur être placés dans /usr/local/share parce que c'est indépendant de l'architecture, mais seulement installé sur une machine? Ou comment sur /var/opt/ parce que c'est la variable de données pour un programme facultatif? Ou peut-être juste /etc depuis les données concernent la configuration de toute façon? À la fin de la journée, il n'a pas de sens et c'est plus facile "de créer votre propre espace" dans un sous-répertoire à côté de la binaire, puis de résoudre des problèmes d'autorisations à l'aide de scripts. Cela finit par être vrai sur les deux plates-formes. /coup de gueule
    • Oui, unix a ses problèmes. IDK comment c'est fait ces derniers temps, mais il y a des années, il a été utilisé pour installer toutes les applications en même temps dans /usr ou /usr/bin ou /usr/local/bin etc. Il est bon d'avoir tous les binaires fournis sur le même dossier et d'un simple $PATH, mais il ne fait presque impossible de le désinstaller manuellement une application, car il n'est pas facile de trouver tous ses fichiers. Unix a été utilisé pour être un système d'exploitation serveur avec peu de changements sur les applications au fil du temps. À cet égard, Windows actuel de la structure est plus simple.
    InformationsquelleAutor Hikari
  4. 2

    C'est 2019, et je viens d'installer le Code de Visual Studio (un produit Microsoft) dans le dossier par défaut de 

    %userprofile%\AppData\Local\Programs\Microsoft VS Code

    C'est probablement pour se déplacer dans l'obligation de disposer d'un administrateur ou de l'invite UAC autoriser l'installation

    InformationsquelleAutor Paiman Roointan
  5. 0

    S'il vous plaît installer les fichiers exécutables pour le dossier %programfiles% dans Windows - un MSI simples en fonction du package d'installation ne peut exécuter un programme d'installation active pour tout nouvel utilisateur qui ouvre une session sur la machine à créer de l'utilisateur fichiers et dossiers spécifiques dans leurs profils dossier %appdata%. Vous voyez ce comportement pour Internet Explorer, Adobe reader, etc. - C'est le petit programme d'installation MSI fenêtre qui apparaît la première fois que vous vous connectez à une machine qui a des applications installées. - Grâce - un système d'admin 🙂

    InformationsquelleAutor AndyAdminCheese
  6. -4

    Mon avis, pour ce que ça vaut, est que l'utilisateur programme spécifique pour les fichiers est juste des ennuis et est un putain de stupide chose à faire.

    Beaucoup plus raisonnable est d'installer différentes versions de votre programme:

    \Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe

    Je place ensuite un amorçage lanceur à:

    \Program Files\Your Program\ProgramLauncher.exe

    Ensuite, l'utilisateur dossier de données d'application ne contiennent données, y compris un fichier INI/XML/fichier de Paramètres qui indique la version du programme que l'utilisateur travaille avec.

    Une telle approche répond à la base locataire de conserver les données et l'exécution de code distincts, permet à chaque utilisateur d'exécuter une version spécifique du code, et offre une petite quantité de dé-duplication en assurant le même code exécutable n'est pas copié plusieurs fois sur les dossiers de l'utilisateur.

    Sinon, aller droit de l'avant avec l'installation de programmes AppData et défaire les ans, il nous a fallu pour parvenir à nettoyer séparation du code et des données. J'ai trouvé ce fil parce que j'ai remarqué que le Chrome et DropBox sont code d'installation AppData. Je vais désinstaller le programme, et modifier les autorisations sur mon dossier AppData à exclure de l'exécution pour s'assurer que je peut facilement repérer d'autres programmes de tenter de faire la même BS.

    • Ce n'est pas l'adresse de l'installation de l'application par l'utilisateur, ce qui signifie seulement que l'utilisateur peut accéder et exécuter le programme. Si vous installez les fichiers de programme, tous les utilisateurs sur le système d'exploitation peut exécuter le programme. En outre, l'installation de l'utilisateur local dossier des fichiers de programme ne nécessite pas d'autorisations d'administrateur. Rappelez-vous, je parle de %LocalAppData%\Programmes qui a été conçu spécifiquement pour l'installation program files. L'application/la séparation des données concept s'applique toujours.
    • Veuillez ne jamais mettre les données dans %ProgramFiles% que ce soit! Avant même de contrôle de compte d'utilisateur, de mettre les fichiers de configuration et les données de l'application dans le dossier de l'application a été mauvaise pratique! (Même si c'était extrêmement commun.)
    InformationsquelleAutor DrunkCodeMonkey