Est-ce qu'AppData est maintenant le lieu "correct" pour installer des applications spécifiques à l'utilisateur (qui modifient leurs propres données)?
Je ne suis probablement qu'épaisse, mais je ne vois pas très bien où je suis supposé installer de «nouveaux» programmes spécifiques à l'utilisateur sur Windows 7 (et vraisemblablement Vista aussi, bien que je n’aie pas encore examiné ce scénario).
Sous Windows XP (à tort ou à raison), nous avons toujours installé nos programmes dans les dossiers situés sous 'Fichiers de programme'et a accepté qu'ils seraient aimables - disponibles pour tout le monde. D'après ce que je peux rassembler sous Windows 7, je suis supposé installer mon logiciel sous le logiciel de l'utilisateur. Données d'application dossier (éventuellement AppData\Local\MyApp). Cela a du sens, mais le fait que ce dossier soit "caché" par défaut signifie que nous allons nous "amuser" en discutant avec nos utilisateurs via des supports.
Je souhaite installer notre logiciel de manière à ce qu'il soit spécifique à l'utilisateur (le bit Utilisateurs de Windows 7 est tout à fait logique), mais je souhaite que l'utilisateur puisse y accéder si nécessaire. Notre programme comprend également un sous-répertoire "data" dans lequel il doit écrire pendant son 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 n'est pas disponible. va être un problème.
Mon problème est juste cet aspect entier de "dossier caché" de AppData. Même si j'ai parcouru le MSDN, je ne peux pas savoir où je suis supposé installer des programmes spécifiques à l'utilisateur. Pris dans un sens, cela semblerait être quelque chose comme AppData\Local\MyApp, et d’une autre manière, il semblerait qu’il soit tout aussi valable sous les droits de l’utilisateur. Mes documents\MonApp équivalent.
Quelqu'un a-t-il un guide clair pour savoir où vont ces choses? J'ai trouvé la documentation MSDN déroutante. :-)
Pas vraiment.
Répertoire qui sert de référentiel Commun pour les données Spécifiques à une application pour l'utilisateur itinérant actuel.
Étonnamment, AppData est destiné aux données d'application et non à l'installation (à part les applications Cliquez une fois/Silverlight). Vous pouvez et devez toujours installer dans Program Files, mais ne vous attendez pas à écrire dans ce dossier.
Vous pouvez installer le logiciel dans AppData si vous souhaitez que celui-ci suive un utilisateur dans un environnement Active Directory, ce qui se produit si vous le mettez dans AppData\Roaming (emplacement SpecialFolder.ApplicationData).
Vous pouvez également installer AppData si vous souhaitez que le logiciel ne soit disponible que pour l'utilisateur qui l'installe. Cela peut être utile si, par exemple, vous avez plusieurs utilisateurs sur le même ordinateur qui souhaitent tous exécuter différentes versions du logiciel de manière totalement isolée.
Si vous souhaitez que les paramètres ne s'appliquent que sur la machine locale, utilisez AppData\Local, qui est SpecialFolders.LocalApplicationData. Les administrateurs AD seront très heureux, car la taille du profil itinérant ne montera pas soudainement à 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
Souvenez-vous de ne jamais vous fier au 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 énumération de dossiers spéciaux dans votre logiciel, ou l’équivalent dans votre programme d’installation.
Ne pourriez-vous pas installer dans Program Files, mais utiliser AppData tel qu'il est censé être utilisé et y stocker votre base de données?
Windows 7 a ajouté le dossier FOLDERID_UserProgramFiles known et, par défaut, il est mappé sur %LOCALAPPDATA%\Programs. Ceci est utilisé par MSI lorsque ALLUSERS = 2 & MSIINSTALLPERUSER = 1 .
Sur Vista et les versions antérieures, il n’existe pas de dossier canonique d’application par utilisateur, mais l’utilisation de %LOCALAPPDATA% est plutôt courante. Malheureusement, MSI utilisera simplement % ProgramFiles% sur ces systèmes.
La structure de dossiers de 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 dossiers, comme Mes documents pour les fichiers dont le contenu est généré par l'utilisateur, AppData Local et Roaming (qu'Unix gère généralement avec NFS).
Il est temps que nous, les développeurs, commencions à utiliser ces structures. Nous devons au moins séparer les fichiers binaires qui n'ont pas besoin d'être répliqués, les paramètres globaux et les paramètres utilisateur.
Lorsqu’une installation installe une application, cette installation doit normalement avoir l’autorisation d’écrire sur Program Files. Une fois la configuration terminée, les fichiers de programme ne doivent être accessibles en écriture que pour les autres configurations visant à mettre à jour les fichiers binaires vers d'autres versions.
Veuillez installer les fichiers exécutables dans le dossier% programfiles% sous Windows. Un simple package d'installation basé sur MSI peut effectuer une configuration active pour tout nouvel utilisateur qui se connecte à la machine afin de créer les fichiers et dossiers spécifiques à l'utilisateur dans leur dossier% appdata%. Vous voyez ce comportement pour Internet Explorer, le lecteur Adobe, etc. - C'est la petite fenêtre du programme d'installation MSI qui apparaît la première fois que vous vous connectez à une machine sur laquelle ces applications sont installées. - Merci - un administrateur système :)
Nous sommes en 2019 et je viens d'installer Visual Studio Code (un produit Microsoft) dans le dossier par défaut de
%userprofile%\AppData\Local\Programs\Microsoft VS Code
Ceci est probablement destiné à éviter l'exigence de demander à un administrateur ou à une invite UAC d'autoriser l'installation.