2008-09-26 4 views
1

Nous avons un programme d'installation MSI pour une application .Net WinForms pour Windows XP qui s'installe et s'exécute uniquement en tant qu'administrateur. Les utilisateurs doivent se connecter à l'application lorsqu'elle fonctionne. Les clients veulent l'installer et s'exécuter sous un compte utilisateur sous Vista, et d'utiliser leur compte Windows. Un aperçu préliminaire à travers le code montre beaucoup de problèmes; le programme d'installation écrit dans le registre et installe l'application dans C: \ Program Files. L'application stocke les préférences utilisateur dans le registre, écrit les données dans C: \ Documents and Settings \ All Users \ et crée des fichiers temporaires dans C :.Règles pour les applications WinForms multi-utilisateurs sur Vista

Je suppose que la première chose à faire est de stocker les fichiers de données dans System.Environment.CommonApplicationData et les préférences de l'utilisateur dans System.Environment.LocalApplicationData. Un compte d'utilisateur peut-il installer une application sur System.Environment.ProgramFiles?

Un problème est que l'application doit pouvoir être installée et désinstallée par n'importe quel utilisateur, et tous les utilisateurs partagent les mêmes fichiers de données. Chaque utilisateur a ses propres préférences.

Y a-t-il un livre ou un site Web qui donne une répartition détaillée de ce qui est requis pour créer une application WinForms qui obéit aux règles pour plusieurs utilisateurs sur Vista?

Editer: J'ai vérifié avec le client et l'exigence d'installer seulement comme un compte d'utilisateur est ferme, ils suppriment l'accès administrateur du personnel de l'étage. Cela exclut les composants installés par l'administrateur et les installations par machine.

Je pensais à créer une application de données distincte qui fonctionnerait sur une machine d'administration à laquelle les machines de plancher se connecteraient via l'accès distant. Toutes les données client seraient stockées sur cette machine. Cependant, cette application devrait également installer et exécuter sous un compte d'utilisateur.

Existe-t-il un livre ou un site décrivant toutes les règles que les applications utilisateur Vista doivent suivre?

Répondre

0

Merci les gars. J'ai vérifié avec le client et l'exigence d'installer seulement comme un compte d'utilisateur est ferme, ils suppriment l'accès administrateur du personnel de l'étage. Cela exclut les composants installés par l'administrateur et les installations par machine.

Notre solution était de créer un nouveau compte utilisateur standard pour notre application. Le personnel qui doit utiliser l'application doit se connecter en tant que cet utilisateur. En fait, cela s'est avéré plus efficace que le partage de données entre utilisateurs parce que nous pouvons maintenant héberger l'application pour différents clients sur la même machine.

J'ai également trouvé une excellente référence pour faire des applications multi-utilisateurs sur Windows, les exigences techniques du logiciel client Microsoft Windows 7 document.

1

« l'application doit être installable et installable par tout utilisateur » « tous les utilisateurs partagent les mêmes fichiers de données »

Vous allez avoir du mal à devoir répondre à ces deux exigences. Les nouvelles fonctions de sécurité de Vista sont conçues pour empêcher les utilisateurs de se piétiner les uns les autres (et sur le système). La seule façon de penser à ce travail est similaire à la façon dont nous avons géré une telle exigence dans un environnement Windows 2000. Vous construisez deux composants - la partie utilisateur de l'application et un composant système qui gère les informations partagées entre les utilisateurs. Un administrateur installe le composant «partagé» (qui inclut un service Windows pour l'exécuter) et chaque utilisateur installe le composant «utilisateur».

Je pense que cela pourrait fonctionner pour votre scénario, mais cela nécessiterait de retravailler votre code qui utilise les fichiers partagés pour parler au service au lieu d'accéder directement à ces fichiers.

Bien sûr, vous pouvez également avoir un outil que l'utilisateur exécute en tant qu'administrateur pour créer votre dossier dans un endroit spécifique et accorder les autorisations de sécurité nécessaires. Cela pourrait fonctionner pour vos objectifs aussi.

1

Vous aurez des problèmes pour permettre l'installation de l'application par n'importe quel utilisateur, et en même temps accéder aux fichiers de données partagés. En effet, votre première exigence implique une installation par utilisateur, tandis que la seconde implique une installation par machine. Laisse-moi expliquer ...

installateurs standard (basés MSI-) peuvent être étendus à être soit par utilisateur ou par machine:

  • par utilisateur installe a mis le programme installé fichiers quelque part dans le répertoire personnel de l'utilisateur. L'application est installée pour cet utilisateur uniquement. Les autres utilisateurs ne voient même pas le programme dans le menu Démarrer ni Ajout/Suppression de programmes. S'ils veulent le programme, ils doivent l'installer eux-mêmes dans leur propre zone par utilisateur. Il peut donc y avoir plusieurs copies du programme installées, et chacune est isolée des autres. Ce type d'installation peut être effectué par des utilisateurs réguliers (non administrateurs), c'est pourquoi ils ne peuvent pas écrire dans des zones partagées telles que "Program Files" ou "All Users".
  • Les installations par machine peuvent modifier les zones partagées du système de fichiers (par exemple, «Program Files» ou «All Users»). Chaque utilisateur voit la même copie du programme dans le menu Démarrer et Ajout/Suppression de programmes. Seuls les utilisateurs administrateurs peuvent effectuer ce type d'installation.
Questions connexes