Je crée une install réseau. J'installe sur le serveur. J'installe sur les
clients à partir du serveur. Ca marche à peu près à ceci près :
lorsque je lance l'appli sur un client il me dit qu'il ne trouve pas le
WDUPDATE.NET.
Il dit que ce fichier doit se trouver dans C:\PROGRAM
FILES\REP_APPLI\NOM_APPLI\
alors que ce fichier se trouve bel et bien dans C:\PROGRAM FILES\REP_APPLI,
c'est à dire le répertoire d'installation de l'appli.
Alors le truc de la mise à jour auto en réseau va chercher ça dans un sous
repertoire que quelque chose a ajouté au chemin.
J'ai regardé dans WDSETUP7 et WDINST, mais je ne trouve rien qui crée ce
chemin erronné.
Comment je peux corriger cette anomalie car je vois déjà le bordel chez le
client.
2e problème :
Toujours pour le même projet où tout allait bien avant (enfin presque), rien
ne va plus maintenant car je ne peux plus créer l'installateur.
Il s'arrête en me disant qu'il ne trouve pas WDSETUP7.EXE et aborte.
Mis à part le fait que j'ai regardé dans le projet WDSETUP (mais je n'ai
rien modifié, ni généré un exe) je n'ai rien fait de particulier et surtout
pas touché à un fichier quelconque.
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et install le de nouveau (version 206g ou h). Je pense que cela fonctionnera. ANtoine.
Jean Passe wrote:
Salut,
j'ajoute que je viens de refaire deux tests sur deux projets différents sans reproduire. As tu essayé (juste pour test) sur un second projet et eventuellement sur une seconde machine de develeoppement. cela te permettrait de vérifier que ce n'est pas ton éditeur qui deconne.
Bon, suis monté de suite au bureau et me suis lancé dedans.
J'ai supprimé, comme conseillait le ST, les reps inst et instgrp du projet. J'ai créé un nouvel exe du projet. J'ai créé une nouvelle installation réseau. J'ai installé la version serveur sur le serveur (si, si...).
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Ben, on va voir. L'installation serveur s'achève correctement semble-t-il. Je me lance dans l'installation client à partir du rep de l'appli sur le serveur (donc C:Proram Filesmon_appliinstall.exe). J'indique le chemin, l'appli est créée.
Anomalie suivante : pas de création de groupe, pas de création d'icone.
Je lance l'appli, et PAN : le WDUPDATE.NET n'est pas trouvé dans C:Program Filesmon_repmon_appliWDUPDATE.NET....... Evidemment, le sousrépertoire mon_appli n'existe pas et est inventé et ajouté par WDINST je présume.
Evidemment, pas de desinstallateur sur le poste client.
Pu.... de truc !
Bon, ne nous décourageons pas : je prend un projet bidon de test, je crée l'exe, je crée l'install réseau.
Je fais l'install serveur, l'install client et c'est pil poil : même message de non partage du rep d'install sur le serveur qui disparaît aussi après avoir sélectionné le rep par le sélecteur, pas de groupe, pas d'icone, pas de desinstallateur sur le client, même sousrépertoire (avec le nom de l'appli) ajouté pour indiquer le chemin de WDUPDATE.NET
Je sens que je vais avoir un malaise....
Suis écoeuré.... :-(((((
A+ Jan Van Wijk
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec
ton tes projet ne cherche pas, dsinstalle windev depuis Windows et install
le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
ANtoine.
Jean Passe wrote:
Salut,
j'ajoute que je viens de refaire deux tests sur deux projets
différents sans reproduire.
As tu essayé (juste pour test) sur un second projet et
eventuellement sur une seconde machine de develeoppement.
cela te permettrait de vérifier que ce n'est pas ton éditeur qui
deconne.
Bon, suis monté de suite au bureau et me suis lancé dedans.
J'ai supprimé, comme conseillait le ST, les reps inst et instgrp du
projet. J'ai créé un nouvel exe du projet.
J'ai créé une nouvelle installation réseau.
J'ai installé la version serveur sur le serveur (si, si...).
Et là, une première anomalie que je n'avais pas remarqué auaparavent :
l'installateur me disait que "le répertoire visé d'install n'était pas
partagé en réseau". Logique que je n'avais pas fait attention avant
car c'est une connerie. Preuve, quand j'ai sélectionné, par le
sélectionneur, le même répertoire (C:Program Files en occurrence)
le message a disparu..... mais je gardais l'espoire que l'origine de
l'anomalie était trouvé.
Ben, on va voir.
L'installation serveur s'achève correctement semble-t-il.
Je me lance dans l'installation client à partir du rep de l'appli sur
le serveur (donc C:Proram Filesmon_appliinstall.exe).
J'indique le chemin, l'appli est créée.
Anomalie suivante : pas de création de groupe, pas de création
d'icone.
Je lance l'appli, et PAN : le WDUPDATE.NET n'est pas trouvé dans
C:Program Filesmon_repmon_appliWDUPDATE.NET.......
Evidemment, le sousrépertoire mon_appli n'existe pas et est inventé et
ajouté par WDINST je présume.
Evidemment, pas de desinstallateur sur le poste client.
Pu.... de truc !
Bon, ne nous décourageons pas : je prend un projet bidon de test, je
crée l'exe, je crée l'install réseau.
Je fais l'install serveur, l'install client et c'est pil poil : même
message de non partage du rep d'install sur le serveur qui disparaît
aussi après avoir sélectionné le rep par le sélecteur, pas de groupe,
pas d'icone, pas de desinstallateur sur le client, même
sousrépertoire (avec le nom de l'appli) ajouté pour indiquer le
chemin de WDUPDATE.NET
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et install le de nouveau (version 206g ou h). Je pense que cela fonctionnera. ANtoine.
Jean Passe wrote:
Salut,
j'ajoute que je viens de refaire deux tests sur deux projets différents sans reproduire. As tu essayé (juste pour test) sur un second projet et eventuellement sur une seconde machine de develeoppement. cela te permettrait de vérifier que ce n'est pas ton éditeur qui deconne.
Bon, suis monté de suite au bureau et me suis lancé dedans.
J'ai supprimé, comme conseillait le ST, les reps inst et instgrp du projet. J'ai créé un nouvel exe du projet. J'ai créé une nouvelle installation réseau. J'ai installé la version serveur sur le serveur (si, si...).
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Ben, on va voir. L'installation serveur s'achève correctement semble-t-il. Je me lance dans l'installation client à partir du rep de l'appli sur le serveur (donc C:Proram Filesmon_appliinstall.exe). J'indique le chemin, l'appli est créée.
Anomalie suivante : pas de création de groupe, pas de création d'icone.
Je lance l'appli, et PAN : le WDUPDATE.NET n'est pas trouvé dans C:Program Filesmon_repmon_appliWDUPDATE.NET....... Evidemment, le sousrépertoire mon_appli n'existe pas et est inventé et ajouté par WDINST je présume.
Evidemment, pas de desinstallateur sur le poste client.
Pu.... de truc !
Bon, ne nous décourageons pas : je prend un projet bidon de test, je crée l'exe, je crée l'install réseau.
Je fais l'install serveur, l'install client et c'est pil poil : même message de non partage du rep d'install sur le serveur qui disparaît aussi après avoir sélectionné le rep par le sélecteur, pas de groupe, pas d'icone, pas de desinstallateur sur le client, même sousrépertoire (avec le nom de l'appli) ajouté pour indiquer le chemin de WDUPDATE.NET
Je sens que je vais avoir un malaise....
Suis écoeuré.... :-(((((
A+ Jan Van Wijk
Jean Passe
Salut,
Juste uen question: puisque les clients sont en indonésie, comment est-tu certain qu'ils n'ont rien fait de spécial pour l'install ?
Je suis sur car je n'ai jamais installé cette installation en clientèle. Je ne suis pas encore assez fou d'installer en clientèle sans avoir testé à fond, que ce soit une appli ou une installation réseau.
As-tu pensé à PcAnywhere pour voir ce qu'il se passe sur les postes
indonésiens
Si t'as l'occase, essaie GoToMyPC, c'est PCAnywhere en n fois mieux.
A+ Jan Van Wijk
Salut,
Juste uen question: puisque les clients sont en indonésie, comment est-tu
certain qu'ils n'ont rien fait de spécial pour l'install ?
Je suis sur car je n'ai jamais installé cette installation en clientèle. Je
ne suis pas encore assez fou d'installer en clientèle sans avoir testé à
fond, que ce soit une appli ou une installation réseau.
As-tu pensé à PcAnywhere pour voir ce qu'il se passe sur les postes
indonésiens
Si t'as l'occase, essaie GoToMyPC, c'est PCAnywhere en n fois mieux.
Juste uen question: puisque les clients sont en indonésie, comment est-tu certain qu'ils n'ont rien fait de spécial pour l'install ?
Je suis sur car je n'ai jamais installé cette installation en clientèle. Je ne suis pas encore assez fou d'installer en clientèle sans avoir testé à fond, que ce soit une appli ou une installation réseau.
As-tu pensé à PcAnywhere pour voir ce qu'il se passe sur les postes
indonésiens
Si t'as l'occase, essaie GoToMyPC, c'est PCAnywhere en n fois mieux.
A+ Jan Van Wijk
Jean Passe
Salut,
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et
install
le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait influencer quelque chose qui est mal fait, je veux dire que même si mon WD serait foireux comment veux-tu qu'il influence un code (p.e. celui qui ajoute un sousrépertoire au chemin pour y chercher de wdupdate.net ou alors celui qui ne crée PAS ce chemin pour y loger le fichier et le loge dans le rep de l'appli) ? WD foireux planterait, perdrait des trucs, etc tout ce que tu veux, mais ne modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST de façon sérieuse et je proposerai que j'envoi un projet bidon qui fait les mêmes conneries. S'ils ne me trouve pas la connerie dans la semaine je prendrai les mesures que j'aurais du prendre il y a des années déjà. Je suis maintenant sur de moi, j'ai décortiqué toute action faite pendant la création de l'exe, de l'install et des installations serveur et client, 'y pas de conneries faites de ma part. Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les licences ne marchent pas pour les uns, elles ne marcheront pas pour les autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en sachant que je n'étais pas abonné à cet époque. Si quelqu'un peux me dire comment je pourrais récupérer cet article sur l'installation réseau, ça serait sympa.
Merci. A+ Jan Van Wijk
Salut,
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec
ton tes projet ne cherche pas, dsinstalle windev depuis Windows et
install
le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait influencer
quelque chose qui est mal fait, je veux dire que même si mon WD serait
foireux comment veux-tu qu'il influence un code (p.e. celui qui ajoute un
sousrépertoire au chemin pour y chercher de wdupdate.net ou alors celui qui
ne crée PAS ce chemin pour y loger le fichier et le loge dans le rep de
l'appli) ?
WD foireux planterait, perdrait des trucs, etc tout ce que tu veux, mais ne
modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST de
façon sérieuse et je proposerai que j'envoi un projet bidon qui fait les
mêmes conneries.
S'ils ne me trouve pas la connerie dans la semaine je prendrai les mesures
que j'aurais du prendre il y a des années déjà.
Je suis maintenant sur de moi, j'ai décortiqué toute action faite pendant la
création de l'exe, de l'install et des installations serveur et client, 'y
pas de conneries faites de ma part.
Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les
licences ne marchent pas pour les uns, elles ne marcheront pas pour les
autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en sachant que
je n'étais pas abonné à cet époque.
Si quelqu'un peux me dire comment je pourrais récupérer cet article sur
l'installation réseau, ça serait sympa.
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et
install
le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait influencer quelque chose qui est mal fait, je veux dire que même si mon WD serait foireux comment veux-tu qu'il influence un code (p.e. celui qui ajoute un sousrépertoire au chemin pour y chercher de wdupdate.net ou alors celui qui ne crée PAS ce chemin pour y loger le fichier et le loge dans le rep de l'appli) ? WD foireux planterait, perdrait des trucs, etc tout ce que tu veux, mais ne modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST de façon sérieuse et je proposerai que j'envoi un projet bidon qui fait les mêmes conneries. S'ils ne me trouve pas la connerie dans la semaine je prendrai les mesures que j'aurais du prendre il y a des années déjà. Je suis maintenant sur de moi, j'ai décortiqué toute action faite pendant la création de l'exe, de l'install et des installations serveur et client, 'y pas de conneries faites de ma part. Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les licences ne marchent pas pour les uns, elles ne marcheront pas pour les autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en sachant que je n'étais pas abonné à cet époque. Si quelqu'un peux me dire comment je pourrais récupérer cet article sur l'installation réseau, ça serait sympa.
Merci. A+ Jan Van Wijk
Romain PETIT
Jean Passe a couché sur son écran :
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Jean Passe a couché sur son écran :
Et là, une première anomalie que je n'avais pas remarqué auaparavent :
l'installateur me disait que "le répertoire visé d'install n'était pas
partagé en réseau". Logique que je n'avais pas fait attention avant car
c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le
même répertoire (C:Program Files en occurrence) le message a disparu.....
mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement
que ton installation sur le serveur se fasse sur une *ressource
partagée* ( \serveurressource ), même si ton serveur est le poste de
développement...
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
jacques trepp
Romain PETIT wrote:
Jean Passe a couché sur son écran :
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
A+
c'est une piste intéressante. si tu n'as pas de ressource partagée, tu peux utiliser la commande SUBST SUBST Z: C:MONREP_PARTAGE ainsi tu installes le serveur sur Z:, et les clients à partir de serveurMONREP_PARTAGE
-- Jacques TREPP AlbyGest
enlever _pasdespam pour me joindre
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004
Romain PETIT wrote:
Jean Passe a couché sur son écran :
Et là, une première anomalie que je n'avais pas remarqué auaparavent
: l'installateur me disait que "le répertoire visé d'install n'était
pas partagé en réseau". Logique que je n'avais pas fait attention
avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le
sélectionneur, le même répertoire (C:Program Files en occurrence)
le message a disparu..... mais je gardais l'espoire que l'origine de
l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement
que ton installation sur le serveur se fasse sur une *ressource
partagée* ( \serveurressource ), même si ton serveur est le poste de
développement...
A+
c'est une piste intéressante. si tu n'as pas de ressource partagée, tu peux
utiliser la commande SUBST
SUBST Z: C:MONREP_PARTAGE
ainsi tu installes le serveur sur Z:, et les clients à partir de
\serveurMONREP_PARTAGE
--
Jacques TREPP
AlbyGest
jacques.trepp_pasdespam@free.fr
enlever _pasdespam pour me joindre
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004
Et là, une première anomalie que je n'avais pas remarqué auaparavent : l'installateur me disait que "le répertoire visé d'install n'était pas partagé en réseau". Logique que je n'avais pas fait attention avant car c'est une connerie. Preuve, quand j'ai sélectionné, par le sélectionneur, le même répertoire (C:Program Files en occurrence) le message a disparu..... mais je gardais l'espoire que l'origine de l'anomalie était trouvé.
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
A+
c'est une piste intéressante. si tu n'as pas de ressource partagée, tu peux utiliser la commande SUBST SUBST Z: C:MONREP_PARTAGE ainsi tu installes le serveur sur Z:, et les clients à partir de serveurMONREP_PARTAGE
-- Jacques TREPP AlbyGest
enlever _pasdespam pour me joindre
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004
Jean Passe
Salut,
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
C'est ce que je croyais aussi, mais non. Le serveur n'est pas le poste de développement, le serveur, ses disques, ses répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont :-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès aux clients, etc.
Et il est clair, rien qu'avec le démarrage de l'install réseau (mais client aussi) il y a un bug : dès le démarrage il me dit que le chemin proposé (par défaut, initialisé dans WDINST, classiquement C:Program Filesmonappli) n'est pas partagé alors qu'il l'est. Après avoir *sélectionné* 'manuellement' par le sélectionneur de répertoires le chemin (identique au chemin par défaut) le message d'alerte disparaît. Envoyer un tel truc en clientèle n'est déjà pas acceptable pour moi (client : j'ai un avertissment lors de l'install, moi : on s'en fout, continuez).
Merci. A+ Jan Van Wijk
Salut,
Et bien je crois que ton problème vient de là : il faut probablement
que ton installation sur le serveur se fasse sur une *ressource
partagée* ( \serveurressource ), même si ton serveur est le poste de
développement...
C'est ce que je croyais aussi, mais non.
Le serveur n'est pas le poste de développement, le serveur, ses disques, ses
répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont
:-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès
aux clients, etc.
Et il est clair, rien qu'avec le démarrage de l'install réseau (mais client
aussi) il y a un bug : dès le démarrage il me dit que le chemin proposé (par
défaut, initialisé dans WDINST, classiquement C:Program Filesmonappli)
n'est pas partagé alors qu'il l'est. Après avoir *sélectionné*
'manuellement' par le sélectionneur de répertoires le chemin (identique au
chemin par défaut) le message d'alerte disparaît.
Envoyer un tel truc en clientèle n'est déjà pas acceptable pour moi (client
: j'ai un avertissment lors de l'install, moi : on s'en fout, continuez).
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
C'est ce que je croyais aussi, mais non. Le serveur n'est pas le poste de développement, le serveur, ses disques, ses répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont :-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès aux clients, etc.
Et il est clair, rien qu'avec le démarrage de l'install réseau (mais client aussi) il y a un bug : dès le démarrage il me dit que le chemin proposé (par défaut, initialisé dans WDINST, classiquement C:Program Filesmonappli) n'est pas partagé alors qu'il l'est. Après avoir *sélectionné* 'manuellement' par le sélectionneur de répertoires le chemin (identique au chemin par défaut) le message d'alerte disparaît. Envoyer un tel truc en clientèle n'est déjà pas acceptable pour moi (client : j'ai un avertissment lors de l'install, moi : on s'en fout, continuez).
Merci. A+ Jan Van Wijk
Antoine
Derniere solution :
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une architecture du genre :
C:Program FilesMonAppliMonAppli MonInstall.exe
Et que toi, tu as cru que WinDev c'était planté et tu as modifié manuellement ton architecture en :
C:Program FilesMonAppliMonInstall.exe
Moi je le voit bien comme cela ?!
Jean Passe wrote:
Salut,
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et install le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait influencer quelque chose qui est mal fait, je veux dire que même si mon WD serait foireux comment veux-tu qu'il influence un code (p.e. celui qui ajoute un sousrépertoire au chemin pour y chercher de wdupdate.net ou alors celui qui ne crée PAS ce chemin pour y loger le fichier et le loge dans le rep de l'appli) ? WD foireux planterait, perdrait des trucs, etc tout ce que tu veux, mais ne modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST de façon sérieuse et je proposerai que j'envoi un projet bidon qui fait les mêmes conneries. S'ils ne me trouve pas la connerie dans la semaine je prendrai les mesures que j'aurais du prendre il y a des années déjà. Je suis maintenant sur de moi, j'ai décortiqué toute action faite pendant la création de l'exe, de l'install et des installations serveur et client, 'y pas de conneries faites de ma part. Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les licences ne marchent pas pour les uns, elles ne marcheront pas pour les autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en sachant que je n'étais pas abonné à cet époque. Si quelqu'un peux me dire comment je pourrais récupérer cet article sur l'installation réseau, ça serait sympa.
Merci. A+ Jan Van Wijk
Derniere solution :
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une
architecture du genre :
C:Program FilesMonAppliMonAppli MonInstall.exe
Et que toi, tu as cru que WinDev c'était planté et tu as modifié
manuellement ton architecture en :
C:Program FilesMonAppliMonInstall.exe
Moi je le voit bien comme cela ?!
Jean Passe wrote:
Salut,
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb
avec ton tes projet ne cherche pas, dsinstalle windev depuis
Windows et install le de nouveau (version 206g ou h). Je pense que
cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait
influencer quelque chose qui est mal fait, je veux dire que même si
mon WD serait foireux comment veux-tu qu'il influence un code (p.e.
celui qui ajoute un sousrépertoire au chemin pour y chercher de
wdupdate.net ou alors celui qui ne crée PAS ce chemin pour y loger le
fichier et le loge dans le rep de l'appli) ?
WD foireux planterait, perdrait des trucs, etc tout ce que tu veux,
mais ne modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST
de façon sérieuse et je proposerai que j'envoi un projet bidon qui
fait les mêmes conneries.
S'ils ne me trouve pas la connerie dans la semaine je prendrai les
mesures que j'aurais du prendre il y a des années déjà.
Je suis maintenant sur de moi, j'ai décortiqué toute action faite
pendant la création de l'exe, de l'install et des installations
serveur et client, 'y pas de conneries faites de ma part.
Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les
licences ne marchent pas pour les uns, elles ne marcheront pas pour
les autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en
sachant que je n'étais pas abonné à cet époque.
Si quelqu'un peux me dire comment je pourrais récupérer cet article
sur l'installation réseau, ça serait sympa.
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une architecture du genre :
C:Program FilesMonAppliMonAppli MonInstall.exe
Et que toi, tu as cru que WinDev c'était planté et tu as modifié manuellement ton architecture en :
C:Program FilesMonAppliMonInstall.exe
Moi je le voit bien comme cela ?!
Jean Passe wrote:
Salut,
Bon, ok, cela semble indiquer que ton WinDev déconne. Si tu as le pb avec ton tes projet ne cherche pas, dsinstalle windev depuis Windows et install le de nouveau (version 206g ou h). Je pense que cela fonctionnera.
Ecoutes, je ne vois pas très bien comment WD en soi pourrait influencer quelque chose qui est mal fait, je veux dire que même si mon WD serait foireux comment veux-tu qu'il influence un code (p.e. celui qui ajoute un sousrépertoire au chemin pour y chercher de wdupdate.net ou alors celui qui ne crée PAS ce chemin pour y loger le fichier et le loge dans le rep de l'appli) ? WD foireux planterait, perdrait des trucs, etc tout ce que tu veux, mais ne modifierait pas de code.
Après une nuit (courte) de bon sommeil, j'ai décidé de relancer le ST de façon sérieuse et je proposerai que j'envoi un projet bidon qui fait les mêmes conneries. S'ils ne me trouve pas la connerie dans la semaine je prendrai les mesures que j'aurais du prendre il y a des années déjà. Je suis maintenant sur de moi, j'ai décortiqué toute action faite pendant la création de l'exe, de l'install et des installations serveur et client, 'y pas de conneries faites de ma part. Faut pas exagérer.
De toutes les façons, si les restrictions de responsabilité dans les licences ne marchent pas pour les uns, elles ne marcheront pas pour les autres non plus :-).
Je vous tiendrai au courant.
D'autre part, le ST me recommande de consulter la LST48 tout en sachant que je n'étais pas abonné à cet époque. Si quelqu'un peux me dire comment je pourrais récupérer cet article sur l'installation réseau, ça serait sympa.
Merci. A+ Jan Van Wijk
Jean Passe
Salut,
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une architecture du genre : C:Program FilesMonAppliMonAppli MonInstall.exe
Sur et certain.
Et que toi, tu as cru que WinDev c'était planté et tu as modifié manuellement ton architecture en : C:Program FilesMonAppliMonInstall.exe
Non....
D'ailleurs, le répertoire de l'appli ne porte pas le nom de l'appli et je me suis posé la question pendant un petit moment si le problème ne venait pas de là, car ils auraient pu coder avec les pieds en reprenant le chemin indiqué, tronquer ce chemin du nom de l'appli pour le rajouter + tard. Mais avec l'install de l'appli bidon, j'ai gardé comme nom de rep le nom de l'appli et il rajoute bien un sousrep du nom de l'appli, donc ce n'est pas ça.
Moi je le voit bien comme cela ?!
Et moi donc ! Tout problème serait résolu.....
Merci Antoine, t'es comme un père pour moi ;-)
A+ Jan Van Wijk
Salut,
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une
architecture du genre :
C:Program FilesMonAppliMonAppli MonInstall.exe
Sur et certain.
Et que toi, tu as cru que WinDev c'était planté et tu as modifié
manuellement ton architecture en :
C:Program FilesMonAppliMonInstall.exe
Non....
D'ailleurs, le répertoire de l'appli ne porte pas le nom de l'appli et je me
suis posé la question pendant un petit moment si le problème ne venait pas
de là, car ils auraient pu coder avec les pieds en reprenant le chemin
indiqué, tronquer ce chemin du nom de l'appli pour le rajouter + tard.
Mais avec l'install de l'appli bidon, j'ai gardé comme nom de rep le nom de
l'appli et il rajoute bien un sousrep du nom de l'appli, donc ce n'est pas
ça.
Lors de l'install sur le serveur, tu est sur de ne pas avoir eu une architecture du genre : C:Program FilesMonAppliMonAppli MonInstall.exe
Sur et certain.
Et que toi, tu as cru que WinDev c'était planté et tu as modifié manuellement ton architecture en : C:Program FilesMonAppliMonInstall.exe
Non....
D'ailleurs, le répertoire de l'appli ne porte pas le nom de l'appli et je me suis posé la question pendant un petit moment si le problème ne venait pas de là, car ils auraient pu coder avec les pieds en reprenant le chemin indiqué, tronquer ce chemin du nom de l'appli pour le rajouter + tard. Mais avec l'install de l'appli bidon, j'ai gardé comme nom de rep le nom de l'appli et il rajoute bien un sousrep du nom de l'appli, donc ce n'est pas ça.
Moi je le voit bien comme cela ?!
Et moi donc ! Tout problème serait résolu.....
Merci Antoine, t'es comme un père pour moi ;-)
A+ Jan Van Wijk
Vincent
Jean Passe a présenté l'énoncé suivant :
Salut,
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
C'est ce que je croyais aussi, mais non. Le serveur n'est pas le poste de développement, le serveur, ses disques, ses répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont :-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès aux clients, etc.
Que le serveur est accès au client, c'est plutot inutile. Celà fait penser que ce n'est pas un serveur dédié. Quand tu installes ton appli 'serveur', il faut le faire à partir d'un poste de travail, et sélectionné ton repertoire sur le serveur. WDInst doit conserver le nom UNC de ce repertoire pour les postes clients futur.
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le problème que tu décris. (d'autres oui, corrigé en 8)
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Jean Passe a présenté l'énoncé suivant :
Salut,
Et bien je crois que ton problème vient de là : il faut probablement
que ton installation sur le serveur se fasse sur une *ressource
partagée* ( \serveurressource ), même si ton serveur est le poste de
développement...
C'est ce que je croyais aussi, mais non.
Le serveur n'est pas le poste de développement, le serveur, ses disques, ses
répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont
:-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès
aux clients, etc.
Que le serveur est accès au client, c'est plutot inutile. Celà fait
penser que ce n'est pas un serveur dédié.
Quand tu installes ton appli 'serveur', il faut le faire à partir d'un
poste de travail, et sélectionné ton repertoire sur le serveur.
WDInst doit conserver le nom UNC de ce repertoire pour les postes
clients futur.
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le
problème que tu décris.
(d'autres oui, corrigé en 8)
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Et bien je crois que ton problème vient de là : il faut probablement que ton installation sur le serveur se fasse sur une *ressource partagée* ( serveurressource ), même si ton serveur est le poste de développement...
C'est ce que je croyais aussi, mais non. Le serveur n'est pas le poste de développement, le serveur, ses disques, ses répertoires et ses fichiers ne peuvent être plus partagés qu'ils ne le sont :-).
Les clients ont bien sur accès au serveur, etc., le serveur à bien sur accès aux clients, etc.
Que le serveur est accès au client, c'est plutot inutile. Celà fait penser que ce n'est pas un serveur dédié. Quand tu installes ton appli 'serveur', il faut le faire à partir d'un poste de travail, et sélectionné ton repertoire sur le serveur. WDInst doit conserver le nom UNC de ce repertoire pour les postes clients futur.
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le problème que tu décris. (d'autres oui, corrigé en 8)
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Jean Passe
Salut,
> Les clients ont bien sur accès au serveur, etc., le serveur à bien sur
accès
> aux clients, etc. Que le serveur est accès au client, c'est plutot inutile. Celà fait penser que ce n'est pas un serveur dédié.
C'était une façon de parler pour exprimer que tout était partagé.... Mais dans le cas d'espèce, ce n'est pas un serveur dédié en effet, mais dans la config grandeur nature chez le client c'est bien le cas.
Quand tu installes ton appli 'serveur', il faut le faire à partir d'un poste de travail, et sélectionné ton repertoire sur le serveur. WDInst doit conserver le nom UNC de ce repertoire pour les postes clients futur.
Tu es sur de ce que tu avances là ? Il faut installer la version serveur à partir d'un client ???
Que le serveur est accès au client, c'est plutot inutile.
Et comment va-t-il faire pour mettre à jour le client ?
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le problème que tu décris. (d'autres oui, corrigé en 8)
Peux-tu me dire lesquels de mes probs ont été corrigés stp ?
Merci. A+ Jan Van Wijk
Salut,
> Les clients ont bien sur accès au serveur, etc., le serveur à bien sur
accès
> aux clients, etc.
Que le serveur est accès au client, c'est plutot inutile. Celà fait
penser que ce n'est pas un serveur dédié.
C'était une façon de parler pour exprimer que tout était partagé....
Mais dans le cas d'espèce, ce n'est pas un serveur dédié en effet, mais dans
la config grandeur nature chez le client c'est bien le cas.
Quand tu installes ton appli 'serveur', il faut le faire à partir d'un
poste de travail, et sélectionné ton repertoire sur le serveur.
WDInst doit conserver le nom UNC de ce repertoire pour les postes
clients futur.
Tu es sur de ce que tu avances là ?
Il faut installer la version serveur à partir d'un client ???
Que le serveur est accès au client, c'est plutot inutile.
Et comment va-t-il faire pour mettre à jour le client ?
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le
problème que tu décris.
(d'autres oui, corrigé en 8)
Peux-tu me dire lesquels de mes probs ont été corrigés stp ?
> Les clients ont bien sur accès au serveur, etc., le serveur à bien sur
accès
> aux clients, etc. Que le serveur est accès au client, c'est plutot inutile. Celà fait penser que ce n'est pas un serveur dédié.
C'était une façon de parler pour exprimer que tout était partagé.... Mais dans le cas d'espèce, ce n'est pas un serveur dédié en effet, mais dans la config grandeur nature chez le client c'est bien le cas.
Quand tu installes ton appli 'serveur', il faut le faire à partir d'un poste de travail, et sélectionné ton repertoire sur le serveur. WDInst doit conserver le nom UNC de ce repertoire pour les postes clients futur.
Tu es sur de ce que tu avances là ? Il faut installer la version serveur à partir d'un client ???
Que le serveur est accès au client, c'est plutot inutile.
Et comment va-t-il faire pour mettre à jour le client ?
J'ai utilisé l'install en réseau en 7.5 et 8 et n'ai jamais eu le problème que tu décris. (d'autres oui, corrigé en 8)
Peux-tu me dire lesquels de mes probs ont été corrigés stp ?
