Chemin UNC et lancement d'une application tierce (DCOM)

mc wrote:

Pour vérifier si le fichier existe, j'utilise
FileSystemObject. Or FSO me dit que le fichier n'existe
pas, alors qu'il existe...

Bonjour,

FileSystemObject supporte à la fois UNC et les drives mappés. Êtes-vous
sûr que le process qui tourne sur PC1 et qui utilise FileSystemObject a
les droits d'accès nécessaires sur PC2?

Si je fais exactement la même chose avec mon
client sur le même PC que mon serveur, alors tout
marche bien!

Sur PC1 et / ou sur PC2? Word est-il installé sur les deux?

Par contre quand je veux démarrer
Word (CreateObject("Word.Application")), ça ne marche pas
non plus...

Qu'est-ce qui ne marche pas? Avez-vous une erreur? Laquelle? Word est il
correctement enregistré sur la machine en question?

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Bonjour et merci de m'aider à trouver où le bas blesse...

FSO: j'utilise fréquemment cet outil et n'ai encore
jamais rencontré ce problème. En fait après
approfondissement il s'avère que lorsque j'appelle mon
application serveur depuis un autre PC, FSO n'arrive pas
à trouver les fichiers en réseau (que ce soit en passant
le chemin UNC ou un chemin sur un drive mappé, et je suis
sure que ces fichiers existent). Les fichiers qui se
trouvent en local, il les trouve sans problème.
Par contre quand j'appelle mon applic server depuis le
même PC, FSO "trouve" tous les fichiers.

Pour info j'ai enregistré mon application serveur via
DCOM, l'utilisateur devant alors être l'appelant. Mais de
toute façon, je suis logguée sur les 2 PC avec le même
login.

Chargement d'une application tierce: l'application n'est
en fait pas Word, mais AutoCAD (Word, c'était pour la
clareté de l'explication... enfin je croyais...).
AutoCAD est installé sur les 2 PC, je peux le démarrer
sans problème sur les 2 PC. Et, là encore, si
l'application client et l'application serveur sont sur le
même PC (PC2), alors tout marche bien.

j'ai continué à gratter un peu, et je trouve ceci dans
l'"event viewer" de Windows:
========================= =======================
Event Type: Warning
Event Source: COM+
Event Category: (106)
Event ID: 4434
Date: 8/18/2004
Time: 11:53:16 AM
User: N/A
Computer: MBOPC98
Description:
A method call to an object in a COM+ application was
rejected because the caller is not properly authorized to
make this call. The COM+ application is configured to use
Application and Component level access checks, and
enforcement of these checks is currently enabled. The
remainder of this message provides information about the
component method that the caller attempted to invoke and
the identity of the caller.
========================= =======================

Je suis sure qu'il y a un rapport avec mon problème, mais
lequel....???

Encore merci pour le coup de main,
Marina

Votre appli serveur fonctionne sous COM+ (a priori oui) ou bien elle est
froidement enregistrée directement (/regserver)?

Dans le premier cas, il faut vérifier dans COM+ les réglages sécurité de
votre appli (Composant | Propriétés | Sécurité). Dans le deuxième cas,
utilisez DCOMCNFG sur le serveur pour définir les autorisations.

Le message de l'event viewer semble effectivement indiquer un problème
de ce type. Vérifiez toutefois que l'heure du message correspond bien à
l'heure de votre tentative. Le nom de la machine étant MB**OPC**98, je
soupçonne qu'il s'y déroule des activités liées à OPC donc au COM. Votre
composant n'est donc probablement pas tout seul.

je suis logguée sur les 2 PC avec le même
login.

S'agit-il de comptes locaux ou de comptes sur un domaine?

Autre chose, si vous avez utilisé DCOMCNFG, il faut que "authentication
level" soit mis à "none". "Packet level authentication" n'est pas
supporté en VB.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

> Votre appli serveur fonctionne sous COM+ (a priori oui)

ou bien elle est

froidement enregistrée directement (/regserver)?

"Froidement" enregistrée via double-click......
Je ne crois pas qu'elle soit sous COM+ (j'avoue que je ne
suis pas sure de savoir comment le déterminer!)

Dans le premier cas, il faut vérifier dans COM+ les

réglages sécurité de

votre appli (Composant | Propriétés | Sécurité). Dans

le deuxième cas,

utilisez DCOMCNFG sur le serveur pour définir les

autorisations.

Avec DCOMCNFG, sous COmputer / My Computer / DCOM Config,
je choisi mon applic et propriétés, dans les choses qui
m'ont l'air importantes (d'après ce que j'ai trouvé dans
les infos MSDN):
Authentication Level: None
Launch Permissions: Allow pour Everyone, Interactive &
System
Access Permissions: Allow pour Everyone, Interactive &
System
Identity: The launching user

Le message de l'event viewer semble effectivement

indiquer un problème

de ce type. Vérifiez toutefois que l'heure du message

correspond bien à

l'heure de votre tentative. Le nom de la machine étant

MB**OPC**98, je

soupçonne qu'il s'y déroule des activités liées à OPC

donc au COM. Votre

composant n'est donc probablement pas tout seul.

Le nom du PC n'a rien à voir avec OPC... C'est juste un
nom de PC qui correspond à une codification en interne.
Disons que pour suivre ma description, j'aurais du
remplacer le nom du PC par PC2.

>je suis logguée sur les 2 PC avec le même
>login.

S'agit-il de comptes locaux ou de comptes sur un

domaine?

Domaine

Je commence à me sentir dépassée par un truc qui me
semblait devoir être tout simple...
Est-il toujours aussi difficile de créer une application
serveur (qui interagit avec le PC où elle est installée
et pas "simplement" par des accès à une base-de-données)?

mc wrote:

"Froidement" enregistrée via double-click......
Je ne crois pas qu'elle soit sous COM+ (j'avoue que je ne
suis pas sure de savoir comment le déterminer!)

Si vous ne l'avez pas explicitement inscrite au catalogue COM+, elle n'y
est pas.

Avec DCOMCNFG, sous COmputer / My Computer / DCOM Config,
je choisi mon applic et propriétés, dans les choses qui
m'ont l'air importantes (d'après ce que j'ai trouvé dans
les infos MSDN):
Authentication Level: None
Launch Permissions: Allow pour Everyone, Interactive &
System
Access Permissions: Allow pour Everyone, Interactive &
System
Identity: The launching user

OK.

Le nom du PC n'a rien à voir avec OPC... C'est juste un
nom de PC qui correspond à une codification en interne.

Raté :-) .

Est-il toujours aussi difficile de créer une application
serveur (qui interagit avec le PC où elle est installée
et pas "simplement" par des accès à une base-de-données)?

Non, c'est en général assez simple, surtout si on ne passe pas par COM+.
Donc résumons:

Il me vient une idée: quand vous tournez client et serveur sur la même
machine, le serveur est déjà enregistré, il n'y a donc pas de problème.
Mais quand le client tourne sur PC2, comment sait-il où se trouve le
composant serveur?

Vous avez 3 moyens de faire savoir au client où le serveur est actif:

1. Utilisation de CliReg32 (voir la doc à ce sujet).

2. Enregistrement du serveur d'abord en local (simple exécution) puis
modification de l'enregistrement avec DCOMCNFG (sur le client) pour
indiquer que le serveur n'est pas local mais remote et sur quel machine.

3. Utilisation de CreateObject avec le nom du composant en 2ème
paramètre.

Si vous n'avez pas utilisé au moins une de ces 3 méthodes, ça ne peut
pas fonctionner. Le COM sur PC2, ne sait pas comment instancier le
serveur remote. Mais d'après ce que vous me dîtes, ce n'est pas le
problème.

J'aurais donc tendance à revenir sur un problème de droits d'accès aux
fichiers de PC2 depuis PC1.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

>Si vous ne l'avez pas explicitement inscrite au

catalogue COM+, elle n'y

est pas.

Je ne saurais pas comment faire, mais si ça peut m'aider,
je peux essayer. pensez-vous que je puisse résoudre ce
problème ainsi???

Il me vient une idée: quand vous tournez client et

serveur sur la même

machine, le serveur est déjà enregistré, il n'y a donc

pas de problème.

Mais quand le client tourne sur PC2, comment sait-il où

se trouve le

composant serveur?

Vous avez 3 moyens de faire savoir au client où le

serveur est actif:

1. Utilisation de CliReg32 (voir la doc à ce sujet).

2. Enregistrement du serveur d'abord en local (simple

exécution) puis

modification de l'enregistrement avec DCOMCNFG (sur le

client) pour

indiquer que le serveur n'est pas local mais remote et

sur quel machine.

3. Utilisation de CreateObject avec le nom du composant

en 2ème

paramètre.

J'ai essayé 1 et 3. Sans succès! :(

J'aurais donc tendance à revenir sur un problème de

droits d'accès aux

fichiers de PC2 depuis PC1.

La question qui tue: comment je fais pour résoudre ce
point????
Etant sur un domaine, je supposais que ça ne poserais pas
de problème...
Faut-il que tous les répertoires de mon PC serveur (PC1)
soient partagés?

Je vais devoir partir d'ici 5 minutes.
J'essaierais de résoudre ce problème demain matin...
Merci encore pour votre aide et j'espère être en mesure
de vous dire quel était mon prblème demain!

Marina

mc wrote:

Si vous ne l'avez pas explicitement inscrite au catalogue COM+, elle
n'y est pas.

Je ne saurais pas comment faire, mais si ça peut m'aider,
je peux essayer. pensez-vous que je puisse résoudre ce
problème ainsi???

Non. COM+ est là pour ajouter une couche deservice supplémentaires à
DCOM. En l'occurence, ça ne résoudra rien.

J'aurais donc tendance à revenir sur un problème de droits d'accès
aux fichiers de PC2 depuis PC1.

La question qui tue: comment je fais pour résoudre ce
point????
Etant sur un domaine, je supposais que ça ne poserais pas
de problème...
Faut-il que tous les répertoires de mon PC serveur (PC1)
soient partagés?

Il faut que le compte sous lequel tourne le process serveur sur PC1 ait
les permissions d'accès sur les fichiers visés sur PC2. Comme vous avez
spécifié "launching user", essayez voir avec Interactive User. Sinon,
avec un autre compte dont vous êtes sûre qu'il a les permissions
requises.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Salut,

Il est fortement déconseillé d'utiliser FSO en VBde toute facon, utilisez
plutot les fonctions implantées ou les APIs.

--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/



mc <anonymous@discussions.microsoft.com> a écrit :

Bonjour,

Voici ma situation:
J'ai un server exe ActiveX qui tourne sur (disons) PC1.
Mon client tourne sur un autre PC (disons PC2)
Quand j'appelle une fonction de mon exe ActiveX, le
programme soit:
1. contrôler qu'un fichier donné existe
2. charger une application tierce (disons word), ouvrir
le fichier et l'imprimer.

Le chemin d'accès au fichier à ouvrir est transmis par
l'application client. Le chemin est au format UNC (mais à
priori même avec un chemin mappé, le problème est le
même).
Pour vérifier si le fichier existe, j'utilise
FileSystemObject. Or FSO me dit que le fichier n'existe
pas, alors qu'il existe...

Maintenant si je transmets le chemin à un fichier qui se
trouve sur PC1 (C:Tempblabla.doc, p.ex.) FSO me dit que
le fichier est bien là. Par contre quand je veux démarrer
Word (CreateObject("Word.Application")), ça ne marche pas
non plus...

Si je fais exactement la même chose avec mon client sur
le même PC que mon serveur, alors tout marche bien!

Qu'est-ce que je ne comprends pas???

>Il est fortement déconseillé d'utiliser FSO en VBde

toute facon, utilisez

plutot les fonctions implantées ou les APIs.

La fonction Dir() ne trouve pas mon fichier non plus.

Pour ma culture: pourquoi est-il déconseillé d'utiliser
FSO? Je l'utilise déjà depuis pas mal de temps et n'ai
jamais rencontré de problème (à part celui de ce thread,
mais à priori le problème n'a rien à voir avec FSO...)

mc wrote:

Le chemin d'accès au fichier à ouvrir est transmis par
l'application client. Le chemin est au format UNC (mais à
priori même avec un chemin mappé, le problème est le
même).

Bonjour,

Il y a quelque chose que je ne saisis pas bien. D'après ce que vous
dîtes, le client envoie le nom UNC du fichier à tester au serveur via
une méthode de ce composant serveur. Correct? Le nom UNC étant
universel, cela me paraît OK car il ne peut y avoir de confusion (sauf
problème de DNS ou de nom BIOS si le nom de la machine n'est pas reconnu
côté serveur - avez-vous vérifié qu'il n'y a pas de problème de ce
côté?).

Mais quand vous dîtes que c'est pareil avec un chemin mappé, cela
veut-il dire que sur toutes les machines le mapping des drives est
exactement identique? Et même, comment-cela est-il possible si PC2
envoit à PC1 le nom d'un fichier local? C: ne peut pas être mappé sur le
serveur.

Cela ne peut pas fonctionner, évidemment, à moins de savoir quel drive
mappé utiliser pour que le serveur ait un chemin d'accès valide ou de ne
passer que le nom de fichiers non locaux.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr