Applis VB6 sur machines avec droits d'accès limités

phil74 wrote:

Bonjour,

Système : NT4, w2000, XP

Comment installer une appli VB6 sur une machine qui ne possède que des
droits d'accès limités ?

Normalement les fichiers du runtime (msvbvm60.dll, oleaut32.dll,
asycfilt.dll,...) sont installés dans windowssystem
Mais pour cela il faut avoir les privilèges d'un administrateur

Que faire si le client n'a pas ces droits et que vous souhaitez qu'il
puissent exécuter votre logiciel écrit sous vb ??????

Toutes infos me serait très utiles
Merci

On peut mettre les dll dans le dossier de l'appli - c'est comme ça que je
fais des applis "sans install".
Toutefois il me semble qu'il y en a certains qu'il faut enregistrer dans le
BdR... A tester sur un PC qui n'a jamais vu d'appli VB6.

Clive

Bonjour,

lorsque tu installes une application VB, l'installeur installe ton
applicatif (exe, mdb, ...) ainsi qu'un certain nombres de "dépendances" et en
particulier les .ocx. Ces obejts nécessitent un enregistrement dans les bases
de registres.

Lorsque ces objets existent déjà dans le système, tu peux parfaitement juste
installer ton .exe qui fonctionnera parfaitement : par exemple, tu peux juste
remplacer ton exécutable (copier/coller) par une nouvelle version sans avoir
à réinstaller. Tu peux copier un deuxième exécutable, sious réserve qu'il
utilise les mêmes contrôles ...

Donc réponse à ta question : ça dépend du poste, mais il suffit de copier
l'exécutable, ce que n'importe quel poste sait faire ...

Bonne réception.

"phil74" a écrit :

Bonjour,

Système : NT4, w2000, XP

Comment installer une appli VB6 sur une machine qui ne possède que des
droits d'accès limités ?

Normalement les fichiers du runtime (msvbvm60.dll, oleaut32.dll,
asycfilt.dll,...) sont installés dans windowssystem
Mais pour cela il faut avoir les privilèges d'un administrateur

Que faire si le client n'a pas ces droits et que vous souhaitez qu'il
puissent exécuter votre logiciel écrit sous vb ??????

Toutes infos me serait très utiles
Merci

Ok et merci de vos réponses.
Cependant je ne parle pas encore d'installer des ocx ou dll diverses, mais
seulement le runtime de vb6.

Dans le cas tordu ou je ne connais pas le systeme du client final (nt, 2000,
xp) je ne suis pas sûr que les librairies du runtime soient déja installées.
Dans ce cas il me faut absolument et au minimun tester leur présence et les
installer le cas échéant.

C'est ce que fait mon installateur (InnoSetup).
Ca marche bien à condition que l'utilisateur possèdent les droits
d'administrateur sur son poste.
Dans le cas contraire il sera impossible à Innosetup d'installer ces
librairies.

Comment faites-vous dans ce cas ?

Est-on obliger d'imposer à l'utilisateur de posséder les droits
d'administrateur pour installer une appli vb ?

Amicalement

"phil74" <dlp@wanadoo.fr> a écrit dans le message de news:
uhmWbllCHHA.468@TK2MSFTNGP06.phx.gbl...

Ok et merci de vos réponses.
Cependant je ne parle pas encore d'installer des ocx ou dll diverses, mais
seulement le runtime de vb6.

Dans le cas tordu ou je ne connais pas le systeme du client final (nt,
2000, xp) je ne suis pas sûr que les librairies du runtime soient déja
installées.
Dans ce cas il me faut absolument et au minimun tester leur présence et
les installer le cas échéant.

C'est ce que fait mon installateur (InnoSetup).
Ca marche bien à condition que l'utilisateur possèdent les droits
d'administrateur sur son poste.
Dans le cas contraire il sera impossible à Innosetup d'installer ces
librairies.

Comment faites-vous dans ce cas ?

Hello,

C'est en fait un cas d'école.
Quand on installe une appli VB6, c'est en général:

- Soit Pour une personne qui est "propriétaire"
(donc administrateur) de sa machine => pas de soucis.

- Soit dans un environnement d'entreprise avec règles de sécurité.
=> c'est le cas habituel.
Dans ce cas, les postes clients et leurs utilisateurs n'ont
pas de droits d'administration MAIS corrolaire direct, il y
a un administrateur du parc. C'est donc à lui qu'il faut s'adresser
pour faire les installs. On en profite pour lui expliquer l'installation
technique, les contraintes de déploiement, on se met d'accord sur les
modalités techniques des release, etc.

Il peut alors adopter la stratégie la plus adaptée pour permettre
l'installation sur un ou plusieurs postes, mettre en place des
scripts automatiques pour les release, etc.

En règle générale, on doit fournir avec son application un
Guide d'installation (Application Run Manual en anglais), lequel
doit contenir une liste exhaustive des contraintes d'install du
programme, et en particulier:
- la liste des DLL, OCX, comosants tiers nécessaires à son exécution
- Le ou les ports dont le programme peut avoir besoin (80, 23, etc.)
- Si le programme accède la bd Registre, liste des clés, etc.
- Occupation mémoire (programme & data), et disque (prog & data)
- Estimation de l'augmentation de taille des données disques
- Fréquence estimée des mises à jours, etc.

Avec tout ça, les administrateurs systèmes sont contents, et toi aussi,
du coup :-)

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
FAQ VB: http://faq.vb.free.fr/

Ok Jean Marc, d'accord pout la méthodologie.
C'est d'ailleurs celle que j'utilise d'habitude (ou tout du moins ça y
ressemble).

Par contre, mon propos portait sur un autre cas que je vais essayer de
décrire plus précisemment:
Prenons par exemple un appli de démonstration qui vante les caractéristiques
du produit complet
Cette appli developpée en vb se charge de faire défiler quelques écrans de
présentation style démonstration animée (capture d'écran, son, vidéo, ...)
Cette appli est gravée sur cd pour être librement distibuée à quiconque
serait interresé pour avoir une présentation rapide du produit

Et bien dans ce cas, il est inconcevable d'accompagner ce cd d'un 'mode
d'emploi' pour 'Administrateur'.
L'utilisateur landa possédant un poste landa (en solo, en réseau, ...) doit
être capable d'exécuter cette appli.

Résultat, je ne sais pas à l'avance qui voudra exécuter cette appli, mais je
dois pourvoir être sûr qu'elle puisse être exécutée même sur un poste à
droits d'accès limité

Voilà la problématique.

Merci d'éclairer ma lanterne

phil74 wrote:

Ok Jean Marc, d'accord pout la méthodologie.
C'est d'ailleurs celle que j'utilise d'habitude (ou tout du moins ça y
ressemble).

Par contre, mon propos portait sur un autre cas que je vais essayer de
décrire plus précisemment:
Prenons par exemple un appli de démonstration qui vante les
caractéristiques du produit complet
Cette appli developpée en vb se charge de faire défiler quelques
écrans de présentation style démonstration animée (capture d'écran,
son, vidéo, ...) Cette appli est gravée sur cd pour être librement
distibuée à quiconque serait interresé pour avoir une présentation
rapide du produit

Et bien dans ce cas, il est inconcevable d'accompagner ce cd d'un
'mode d'emploi' pour 'Administrateur'.
L'utilisateur landa possédant un poste landa (en solo, en réseau,
...) doit être capable d'exécuter cette appli.

Résultat, je ne sais pas à l'avance qui voudra exécuter cette appli,
mais je dois pourvoir être sûr qu'elle puisse être exécutée même sur
un poste à droits d'accès limité

Voilà la problématique.

Merci d'éclairer ma lanterne

Phil,

Comme j'ai dit précedemment, il suffit "dans la plupart des cas" d'inclure
les dll idoines dans le repertoire de l'appli.
Pour tester il te faut un PC "vierge" c.a.d. qui n'a jamais vu d'install
d'appli VB6.
Tu copies l'appli dans un dossier et tu le lances, tu vois quel dll manque,
tu copies le dll dans le dossier.
Repeter jusqu'à ce que cela marche et tu commences à avoir des messages
d'erreur d'objet qui indiquent qu'il manque des dll enregistrés

S'il y a des dlls qui ont besoin d'être enregistrés, tu pourras
(normalement) faire un test en lisant la BdR pour voir s'ils sont présents
déjà.
Par exemple, j'ai un appli qui a besoin de MDAC, avant d'instancier un objet
bdd, je vérifie dans la BdR la version de MDAC installé - si présent et
assez récent, je ne fait rien, si ancien ou absent, je lance l'install.

Evidemment, si le compte utilisé pour le"demo" n'a pas les droit suffisants,
il n'y a pas moyen de registrer les dll, il faut contourer en utilisant soit
des contrôles intégrés de Windows, soit des appels API.

Clive

Bonjour,

une remarque supplémentaire à celle de Jean-Marc. Si les entreprises
suppriment les droits d'administration à l'utilisateur final, c'est justement
pour éviter que les utilisateurs installent n'importe quelle application en
général, et des applications malicieuses en particulier.

Sauf à te mettre d'accord avec l'administrateur réseau, tu vas te heurter à
la volonté délibérée de l'entreprise de te compliquer la tache ...

"phil74" a écrit :

Ok Jean Marc, d'accord pout la méthodologie.
C'est d'ailleurs celle que j'utilise d'habitude (ou tout du moins ça y
ressemble).

Par contre, mon propos portait sur un autre cas que je vais essayer de
décrire plus précisemment:
Prenons par exemple un appli de démonstration qui vante les caractéristiques
du produit complet
Cette appli developpée en vb se charge de faire défiler quelques écrans de
présentation style démonstration animée (capture d'écran, son, vidéo, ...)
Cette appli est gravée sur cd pour être librement distibuée à quiconque
serait interresé pour avoir une présentation rapide du produit

Et bien dans ce cas, il est inconcevable d'accompagner ce cd d'un 'mode
d'emploi' pour 'Administrateur'.
L'utilisateur landa possédant un poste landa (en solo, en réseau, ...) doit
être capable d'exécuter cette appli.

Résultat, je ne sais pas à l'avance qui voudra exécuter cette appli, mais je
dois pourvoir être sûr qu'elle puisse être exécutée même sur un poste à
droits d'accès limité

Voilà la problématique.

Merci d'éclairer ma lanterne

Bonjour à tous,
C'est un sacré problème auquel je suis confronté régulièrement.
2 petites remarques, pour apporter de l'eau au moulin...
1. Il existe maintenant deux softs fabuleux qui permettent d'expérimenter le
bon fonctionnement d'un kit d'install, ou bien d'un programme dans un
environnement vierge : VMWare et Virtual PC.
Ces machines virtuelles m'ont changé la vie (comme les rack et les ghosts il
y a quelques années, après le multiboot... bref, j'suis un vieux c...), tu
peux faire des install 'vierge' d'une part en reproduisant au plus juste
l'environnement cible de tes applications (droits etc...), c'est génial
2. Concernant la distribution simple d'une appli VB, effectivement en
mettant msvbrun*.dll et surtout vb6fr.dll (les messages d'erreur en
français... super...) ça suffit pour faire tourner du basic.
La pluspart du temps les OCX ou certaines DLL nécessitent un regsvr32
(enregistrement dans la base des registres)
Par défaut, ça part dans le localmachine, endroit où une personne non admin
n'a pas le droit d'écrire.
Il existe une API Windows, qui permet de rediriger vers n'importe quel autre
endroit de la machine (notament le localuser, où un utilisateur a le droit
normalement d'écrire) : RegOverridePredefKey
On peut donc, par programmation, à chaque démarrage d'un programme VB,
ré-enregistrer systématiquement les OCX et DLL nécesssaire dans la base des
registres...

A+

"SAISAS" a écrit :

Bonjour,

une remarque supplémentaire à celle de Jean-Marc. Si les entreprises
suppriment les droits d'administration à l'utilisateur final, c'est justement
pour éviter que les utilisateurs installent n'importe quelle application en
général, et des applications malicieuses en particulier.

Sauf à te mettre d'accord avec l'administrateur réseau, tu vas te heurter à
la volonté délibérée de l'entreprise de te compliquer la tache ...

"phil74" a écrit :

> Ok Jean Marc, d'accord pout la méthodologie.
> C'est d'ailleurs celle que j'utilise d'habitude (ou tout du moins ça y
> ressemble).
>
> Par contre, mon propos portait sur un autre cas que je vais essayer de
> décrire plus précisemment:
> Prenons par exemple un appli de démonstration qui vante les caractéristiques
> du produit complet
> Cette appli developpée en vb se charge de faire défiler quelques écrans de
> présentation style démonstration animée (capture d'écran, son, vidéo, ...)
> Cette appli est gravée sur cd pour être librement distibuée à quiconque
> serait interresé pour avoir une présentation rapide du produit
>
> Et bien dans ce cas, il est inconcevable d'accompagner ce cd d'un 'mode
> d'emploi' pour 'Administrateur'.
> L'utilisateur landa possédant un poste landa (en solo, en réseau, ...) doit
> être capable d'exécuter cette appli.
>
> Résultat, je ne sais pas à l'avance qui voudra exécuter cette appli, mais je
> dois pourvoir être sûr qu'elle puisse être exécutée même sur un poste à
> droits d'accès limité
>
> Voilà la problématique.
>
> Merci d'éclairer ma lanterne
>
>
>