AppData est-il maintenant l'endroit "correct" pour installer des applications spécifiques à l'utilisateur (qui modifient leurs propres données)?
Je suis probablement juste Très Épais ici, mais il n'est pas clair pour moi où je suis censé installer de "nouveaux" programmes spécifiques à L'utilisateur sur Windows 7 ( et probablement Vista aussi, bien que je n'ai pas encore regardé spécifiquement ce scénario).
Sous Windows XP (à tort ou à raison), nous avons toujours installé nos programmes dans des dossiers sous ' Program Files ' et avons accepté qu'ils soient disponibles pour tout le monde. D'après ce que je peux rassembler sous Windows 7 je suis censé installer mon Logiciel sous le dossier AppData de l'utilisateur (éventuellement AppData Local MyApp). Cela a un certain sens, mais le fait que ce dossier soit "caché" par défaut signifie que nous allons nous amuser à parler à nos utilisateurs via le support.
Je veux installer notre logiciel afin qu'il soit spécifique à l'utilisateur (le bit des utilisateurs dans Windows 7 a un sens parfait) mais je veux que l'utilisateur puisse y accéder si nécessaire. Notre programme comprend également un sous-répertoire' data ' dont il a besoin écrire dans pendant 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 se trouvant dans un dossier spécifique à l'utilisateur ne va pas être un problème.
Mon problème est juste tout cet aspect 'dossier caché' D'AppData. Autant que j'ai chaluté le MSDN, Je ne peux pas travailler où d'autre je suis censé installer des programmes spécifiques à l'utilisateur. Prise dans un sens, il semble être quelque chose comme AppDataLocalMonappli, et une autre façon, il semblerait tout aussi valide sous l'équivalent Mes DocumentsMyApp de l'utilisateur.
Quiconque A un guide clair pour savoir où tout ça va? J'ai trouvé les documents MSDN confus. :-)
5 réponses
Pas vraiment.
Le répertoire qui sert de référentiel pour application spécifique données pour l'utilisateur itinérant actuel.
AppData est, étonnamment, pour les données d'application, pas pour l'installation(cliquez une fois / applications Silverlight de côté). Vous pouvez, et devriez toujours installer dans des fichiers de programme, ne vous attendez pas à écrire dans ce dossier.
Vous pouvez installer le logiciel dans AppData si vous voulez qu'il suive un utilisateur dans un Environnement de répertoire, ce qui se produit si vous le mettez dans AppData \ Roaming (l'emplacement SpecialFolder.ApplicationData).
Vous pouvez également installer dans AppData si vous voulez que le Logiciel soit disponible uniquement pour l'utilisateur qui l'installe. Cela peut être utile si, par exemple, vous avez plusieurs utilisateurs sur la même machine, qui veulent tous exécuter différentes versions du logiciel en toute isolation.
Si vous voulez que les paramètres ne s'appliquent qu'à la machine locale, vous utilisez AppData \ Local, qui est SpecialFolders.LocalApplicationData - cela rendez les administrateurs D'annonces très heureux car la taille du profil itinérant ne va pas soudainement augmenter de 50 Mo ou quelle que soit la taille de votre logiciel.
Si vous voulez créer des paramètres qui s'appliquent à tous les utilisateurs, alors vous regardez SpecialFolders.CommonApplicationData
Vous devez vous rappeler de ne jamais compter sur le nom réel du répertoire - les problèmes de localisation signifient que cela peut changer et que l'emplacement change avec les versions deux du système D'exploitation. Vous devriez utiliser l'énumération dossier spécial dans votre logiciel, ou équivalent dans votre programme d'installation.
Pourriez-vous ne pas installer dans des fichiers de programme, mais utiliser AppData comme il est censé être utilisé, et stocker votre base de données là-bas?
Windows 7 a ajouté le dossierFOLDERID_UserProgramFiles connu et par défaut cela correspond à %LOCALAPPDATA%\Programs. Ceci est utilisé par MSI lorsque ALLUSERS=2 & MSIINSTALLPERUSER = 1.
Sur Vista et plus tôt, il n'y a pas de dossier d'application canonique par utilisateur, mais l'utilisation de %LOCALAPPDATA% est assez courante. Malheureusement, MSI utilisera simplement %ProgramFiles% sur ces systèmes.
La structure des dossiers Windows 7 est profondément inspirée de la structure Unix:
/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, comme Mes Documents pour les fichiers avec du contenu Produit par l'utilisateur, AppData Local et Roaming (que Unix gère habituellement avec NFS).
Il est temps pour nous développeurs de commencer à utiliser ces structures. Nous devons séparer au moins les fichiers binaires qui n'ont pas besoin d'être répliqués, les paramètres globaux et utilisateur.
Lorsqu'une installation installe une application, cette configuration devrait autorisation d'écrire sur des fichiers de programme. Une fois l'installation terminée, les fichiers de programme doivent être inscriptibles uniquement pour les autres configurations visant à mettre à jour les binaires vers d'autres versions.
Veuillez installer des fichiers exécutables dans le dossier% programfiles % dans Windows - un simple package d'installation basé sur MSI peut effectuer une configuration active pour tout nouvel utilisateur qui se connecte à la machine pour créer les fichiers et dossiers spécifiques à l'utilisateur dans leur dossier profiles % appdata%. Vous voyez ce comportement pour Internet Explorer, Adobe reader, etc. - C'est la petite fenêtre d'installation MSI qui apparaît la première fois que vous vous connectez sur une machine qui a ces applications installées. - Merci-un administrateur système:)
Mon opinion, pour ce que ça vaut, est que les fichiers de programme spécifiques à l'utilisateur ne demandent que des problèmes et sont une chose stupide à faire.
Une approche beaucoup plus sensée consiste à installer différentes versions de votre programme pour:
\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 placerais alors un lanceur d'amorçage à:
\Program Files\Your Program\ProgramLauncher.exe
Ensuite, le dossier user Application data contiendra uniquement data , y compris un fichier INI / XML / Settings qui indique la version du programme que cet utilisateur travaille avec.
Une telle approche satisfait le locataire principal de garder les données et d'exécuter du code séparément, permet à chaque utilisateur d'exécuter une version spécifique du code et offre une petite quantité de déduplication en veillant à ce que le même code exécutable ne soit pas copié plusieurs fois dans les dossiers de l'utilisateur.
Sinon, allez - y avec l'installation de programmes à AppData et défaire les années qu'il nous a fallu pour parvenir à une séparation propre du code et des données. J'ai trouvé ce fil parce que j'ai remarqué que Chromium et DropBox installent du code sur AppData. Je vais désinstaller ces programmes et modifier les autorisations sur mon dossier AppData pour exclure l'exécution afin de m'assurer que je peux facilement repérer d'autres programmes essayant le même BS.