Discussion :

[juniorAl]

Je découvre un problème lors du déploiement de mon appli sur VISTA.
Au démarrage celle-ci fait un accès à al registry et dans un fichier XML de conf.
ET mauvaise surprise, ni l'un ni l'autre ne fonctionne :
1 - alors que lors de l'accès registry j'ai écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
 
        public enum eBANK_REG { CLASS_ROOT, CURRENT_CONFIG, CURRENT_USER, LOCAL_MACHINE, USERS };
        private string key;
 
        public bool Write(eBANK_REG bank, string SubKey, string ValueName, string Value)
        {
            bool ret = true;
            RegistryKey rk = null;
            string sKey = string.Concat(key + @"\", SubKey);
            try
            {
                switch (bank)
                {
                    case eBANK_REG.CLASS_ROOT:
                        rk = Registry.ClassesRoot.OpenSubKey(sKey, true);
                        break;
                    case eBANK_REG.CURRENT_CONFIG:
                        rk = Registry.CurrentConfig.OpenSubKey(sKey, true);
                        break;
                    case eBANK_REG.CURRENT_USER:
                        rk = Registry.CurrentUser.OpenSubKey(sKey, true);
                        break;
                    case eBANK_REG.LOCAL_MACHINE:
                        rk = Registry.LocalMachine.OpenSubKey(sKey, true);
                        break;
                    case eBANK_REG.USERS:
                        rk = Registry.Users.OpenSubKey(sKey, true);
                        break;
                    default:
                        break;
                }
                try
                {
                    rk.SetValue(ValueName, Value);
                }
                catch (Exception e)
                { return false; }
            }
            catch { return false; }
            return ret;
        }
        public string Read(eBANK_REG bank, string SubKey, string ValueName)
		{
            string ret;
            RegistryKey rk = null;
            string sKey = string.Concat(key + @"\", SubKey);
			try
			{
                switch (bank)
                {
                    case eBANK_REG.CLASS_ROOT:
                        rk = Registry.ClassesRoot.OpenSubKey(sKey);
                        break;
                    case eBANK_REG.CURRENT_CONFIG:
                        rk = Registry.CurrentConfig.OpenSubKey(sKey);
                        break;
                    case eBANK_REG.CURRENT_USER:
                        rk = Registry.CurrentUser.OpenSubKey(sKey);
                        break;
                    case eBANK_REG.LOCAL_MACHINE:
                        rk = Registry.LocalMachine.OpenSubKey(sKey);
                        break;
                    case eBANK_REG.USERS:
                        rk = Registry.Users.OpenSubKey(sKey);
                        break;
                    default:
                        break;
                }
				try
				{
                    ret = (string)rk.GetValue(ValueName, string.Empty);
                                }
                catch { return string.Empty; }
			}
			catch {return string.Empty;}
            return ret;
		}
        public reg(string Key)
        {
            // autorisation d'acces en lecture et écriture à la Registry
            RegistryPermission f = new RegistryPermission(RegistryPermissionAccess.AllAccess, Key);
            f.Assert();
            this.key = Key;
        }

si je ne donne pas à MonAppli.exe le niveau de privilège "Executer en tant qu'administrateur" l'accès en écriture en Registry ne se fait pas.
Décidément VISTA est toujours aussi surprenant
Je croyais lui avoir donné tous les droits ????
Alors j'ai cherché comment donner toujours à MonAppli.exe ce privilège.
J'ai trouvé quelque chose en exécutant un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
sdbinst.exe" -q "#APPPATH\Vista\Compatibilite_Vista.sdb"

à l'aide de dotNetInstaller lors de l'installation une fois que mon appli est déployée sur le poste VISTA.
Pour générer le Compatibilite_Vista.sdb j'ai utilisé Compatibility Administrator 5.0 et j'ai créé un ApplicationFix auquel j'ai juste donné DisableNXHideUI ET rajouté ForceAdminAccess comme compatibility Modes

et bien ça n'y fait rien !

VISTA c'est désespérant...


2 - Lors de L'accés au XML de conf je dois la 1er fois lui donner le mode de compatibilité "Executer de programme en mode Windows XP", sinon j'ai une exeption lors de l'accès au fichier en écriture qui n'est jamais levée en XP.

????


Est-ce que quelqu'un peut m'indiquer les Best practice pour un déploiment de ce type sur VISTA ?

[smyley]

- Pour le registre :
Qu'est-ce que tu essayes de faire au juste ? Tu donnes Write et Read (que j'ai pas lu), mais comment appelles-tu ces fonctions ? Et d'ailleurs, pourquoi est-ce que tu as besoin d'accéder au registre ?

- Pour le fichier xml :
Il est où ? Parce que si ton application s'installe comme je le pense, alors il est installé dans Program Files et un programme ne devrais pas modifier sa configuration dans Program Files.
Tout programme compatible Vista (et Seven, par extension) doit avoir ses fichiers de configurations dans le dossier de l'utilisateur. La solution que j'ai employée dans DreamShield est d'avoir un fichier de configuration par défaut installé dans Program Files et à l'exécution, si aucun fichier n'est présent dans le dossier de l'utilisateur je copie ce fichier par défaut et ensuite je l'utilise et là, on peut effectivement le modifier sans les droits d'administrateur.

Si tu veux tu peut regarder ce lien qui donne les grandes lignes : http://69.10.233.10/KB/vista/Certified_for_Vista.aspx
(la seule chose que je nuance c'est d'utiliser DreamShield comme installeur )

[olibara]

Merci pour ces info Smyley

La solution que j'ai employée dans DreamShield est d'avoir un fichier de configuration par défaut installé dans Program Files et à l'exécution, si aucun fichier n'est présent dans le dossier de l'utilisateur je copie ce fichier par défaut et ensuite je l'utilise et là, on peut effectivement le modifier sans les droits d'administrateur.

C'est exactement la meme solution que j'emploie

Mais pour le registry c'est une autre galere :

La creation de clef registry dans LOCAL_MACHINE qui ne fonctionne pas sans lancer l'application avec les droits administrateur

Pire !! : Si on execute l'operation en debug a partir de Visual Studio, une clef virtuelle est créee !
Mais si on lance l'application en mode normal c'est une autre clef qui est recherchée !!

[smyley]

La creation de clef registry dans LOCAL_MACHINE qui ne fonctionne pas sans lancer l'application avec les droits administrateur

C'est le comportement normal, y compris sur Seven. On doit avoir les droits d'administrateurs pour écrire dans HKEY_LOCAL_MACHINE ou encore dans C:\Program Files\ ou encore dans C:\Windows, etc. C'est tout à fait cohérent. Une application qui n'a pas les droits d'administrateurs ne devrait pas tenter d'écrire dans ces clefs.
Il y a alors deux comportement :
- Si l'application n'a pas de manifest Vista alors Vista crée des clefs virtuelles pour que l'application continue de fonctionner à peut près correctement et donc pour cet utilisateur, l'application fonctionnera comme si elle était administrateur.
- Si l'application a un manifest Vista, c'est qu'elle a été conçue pour Vista et dans ce cas l'accès est refusé.

Pire !! : Si on execute l'operation en debug a partir de Visual Studio, une clef virtuelle est créee !

VS 2005 ? Parce qu'avec VS 2008 ça n'arrive normalement pas vu qu'un manifest Vista est inclu par défaut dans le programme (et que VS demande à s'exécuter en admin pour débugger une application ayant un manifest indiquant la nécessité de s'exécuter en admin).

[olibara]

Salut Smyley

VS 2005 ? Parce qu'avec VS 2008 ça n'arrive normalement pas vu qu'un manifest Vista est inclu par défaut dans le programme (et que VS demande à s'exécuter en admin pour débugger une application ayant un manifest indiquant la nécessité de s'exécuter en admin).

Et ben non ! je suis en VS Express 2008, je vais un peu investiguer selon tes indications

Ce que je trouve désespérant c'est qu'etant déja admin de ma machine sans autre utilisateur je dois en plus penser a lancer l'application en mode admin pour enregistrer les clefs.

[smyley]

Et ben non ! je suis en VS Express 2008, je vais un peu investiguer selon tes indications

Et tu n'as pas touché au manifest ? tu n'utilises pas un fichier .rc perso ?

Ce que je trouve désespérant c'est qu'etant déja admin de ma machine sans autre utilisateur je dois en plus penser a lancer l'application en mode admin pour enregistrer les clefs.

Question suivante : pourquoi doit tu enregistrer tes clefs dans LOCAL_MACHINE ? Si c'est indispensable, met un manifest Vista avec requireAdministrator et comme ça ton application demandera systématiquement les droits d'admin au démarrage. Si ce n'est pas utile (sauvegardes, configurations, etc.) il faut coder plus proprement (ie. enregistrer dans les dossiers de l'utilisateur ce qui concerne l'utilisateur).

[olibara]

Une machine peut avoir plusieurs utilisateur

Une licence est octroyée pour tous les utilisateurs de la machine
Il est donc logique d'enregistrer la clef de licence une seule fois dans local_machine

Cependant seul l'utilisateur A est admin sur cette machine
C'est donc lui qui procede a l'installation demande, les clef, execute la procedure d'enregistrement et se ramasse le message prevu a cet effet qui lui dit qu'il n'a pas les droits admin et dans ce cas c'est 8 fois sur 10 un utilisateur frustré et une surcharge de support pour expliquer comment faire a un utilisateur de bonne volonté mais cependant énervé !!

Quelque soient les technologies c'est en définitive le confort de l'utilisateur qui donne la raison !

Et je comprend pourquoi un grand nombre d'IT manager gardent leur XP jalousement > 65 % contre 22% pour vista

[smyley]

Une licence est octroyée pour tous les utilisateurs de la machine
Il est donc logique d'enregistrer la clef de licence une seule fois dans local_machine

Dans ce cas l'application doit avoir deux modes. Normalement l'installation et l'activation de la clef doivent se faire pendant l'installation du programme et dans ce cas on peut exécuter un programme pendant l'installation et ce dernier sera exécuté en mode administrateur (elle doit quand même avoir le manifest vista requireAdministrator pour se débarrasser définitivement de la virtualisation) et inscrira la clef dans LOCAL_MACHINE. Ensuite, le produit en lui même devrais avoir un manifest Vista avec asInvoker et n'utiliser la clef de LOCAL_MACHINE qu'en lecture seule et dans ce cas ça marche. (Attention à comment on ouvre un RegistryKey en C# car il y a un paramètre pour indiquer le mode d'ouverture qui est ReadOnly ou ReadWrite).

Ou alors, s'il faut le faire après l'installation on doit avoir un produit avec un manifest asInvoker, et le bouton "Activer" ou "Enregistrer le produit" devrais lancer une autre application externe qui elle aurai un manifest requireAdministrator et qui ferai le travail d'enregistrement.

Quand c'est bien découpé, le produit ne devrais demander pour la première méthode l'élévation que pour l'installation, et dans la deuxième méthode l'élévation juste pour l'installation et pour l'enregistrement lors du premier lancement a priori. Ensuite, toutes les autres exécutions devraient se faire avec asInvoker et donc sans aucun message pour l'utilisateur.

L'UAC de Vista n'est pas fondamentalement incorrect, c'est plutôt XP qui a induit de mauvaises habitudes (vu que par défaut tout le monde est Administrateur sur XP et que donc toutes les applications ont eu l'habitude de s'exécuter avec tous les droits d'administrateur) et le fait que Vista augmente la sécurité frustre tout le monde parce que les applications programmées sans soucis de sécurité sur XP ne fonctionnent plus avec Vista ...