Bonjour Ã*** tous,

Je tente de porter une application ASP basée sur IIS4, NT4 et SQL Server 7
vers une plate-forme IIS6, Windows 20003 et SQL Server 2000.

Dans le global.asa, dans Application_OnStart se trouve le code suivant :

Set ObjMoa = Nothing
Set Application("MOA") = Nothing
Set objMOA = Server.CreateObject("MOA.Application")
Set Application("MOA") = objMOA

Il s'agit d'utiliser dans toute l'application, dans un espace commun Ã***
toutes les sessions une instance d'une DLL écrite en VB6. Ce code fonctionne
parfaitement sous la plate-forme actuelle, mais sous la plate-forme cible,
j'obtiens le message d'erreur suivant :

Objet Application erreur 'ASP 0197 : 80004005'

Utilisation d'objet non autorisée

/LM/W3SVC/1/Root/Test/global.asa, ligne 22

Seuls les objets dont le comportement est celui du modèle Apartment peuvent
être ajoutés Ã*** l'objet intrinsèque de l'application.


L'erreur intervient sur la ligne Set Application("MOA") = objMOA et ne se
produit plus si elle est modifiée en Set Session("MOA") = objMOA.

Comment obtenir les propriétés de partage d'une variable application sous
IIS6 dans ce cas?


Merci par avance de vos réponses.

Je n'en suis plus très sûr mais à mon avis, vous ne pouvez pas sans réécrire
ou recompiler le serveur COM MOA.Application. Le problème ici est que si le
serveur MOA.Application n'est pas de type Apartment, l'ajout d'un tel objet
sour IIS4 faisait automatiquement passer le mode de fonctionnement de IIS4
du modèle multi-thread vers le modèle single-thread; avec la sérieuse perte
de performance concomitante affectant *tous* les sites web situés sur ce
serveur. Avec IIS6, ce comportement a été banni.

Avec IIS, il est possible de déclarer un répertoire web comme étant une
application (isolée des autres applications et de l'application de base) et
de configurer ce répertoire avec des propriétés distinctes. Peut-être qu'en
regardant de ce côté-là, vous pourrez reconfigurer cette (sous-)application
web de façon à pouvoir stocker votre objet compilé sous ce modèle
particulier. C'est simplement une vague idée que je vous dis-là car c'est
le genre de chose que je n'ai plus regardé depuis plusieurs années.

La méthode moderne de partager de l'information entre plusieurs sessions est
tout simplement de stocker l'information dans une base de donnée. Toutes
les autres méthodes entrainent généralement une perte de performance; y
compris dans les cas où vous stockez un object de type Apartment (je ne suis
plus sûr de l'exact dénomination ici; les années ayant fait leur ravage)
puisque vous êtes alors dans la situation où un object potentiellement
inutilisé pendant de longues périodes (minutes, heures, jours, mois et même
années, décennies) occupe inutilement de la place en mémoire vide pendant
tout ce temps-là.

Même dans le cas de Session, MS décourageait l'utilisation de stockage
d'objets "stateful" et la méthode recommandée était d'avoir des objets de
type "stateless" managé par Transaction Server (avec l'information
permanente requise par ces "business objects" stockée dans une bdd).
Aujourd'hui, MS décourage tout simplement l'utilisation de COM dans tous les
cas de nouveau développement. Ce n'est pas pour rien que VB6 n'est plus
vendu par MS (et probablement qu'il va vous être difficile de trouver de la
documentation à ce sujet-là sur internet pour la même raison).

Finalement, comme ma mémoire a subi l'outrage des années, il est fort
possible que je vous ai donnée des renseignements plus ou moins faux dans ce
post; ayant moi-même pratiquement tout oublié à ce sujet-là. Si c'est le
cas, je m'en excuse d'avance mais je n'ai pas l'intention de commencer une
vive discussion ici ou d'entamer des recherches approfondies sur internet.
Pour moi, VB6 a été submergé dans les profondeurs du passé et ce n'est pas
là quelque chose que j'ai l'intention de ramener à la surface; mis-à-part
quelques vagues reflets sous-marins.

Dans votre cas, si vous n'êtes pas capable de résoudre ce problème soit en
reconfigurant IIS6, en recompilant MOA.Application sous un autre mode ou en
remplaçant MOA.Application par autre chose; la meilleure idée serait
peut-être tout simplement de conserver NT4; possiblement en le faisant
tourner dans une machine virtuelle.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Arthur" <Arthur***discussions.microsoft.com> wrote in message
news8973F42-6583-4ECD-92D7-6585DFC7457C***microsoft.com...
> Bonjour à tous,
>
> Je tente de porter une application ASP basée sur IIS4, NT4 et SQL Server 7
> vers une plate-forme IIS6, Windows 20003 et SQL Server 2000.
>
> Dans le global.asa, dans Application_OnStart se trouve le code suivant :
>
> Set ObjMoa = Nothing
> Set Application("MOA") = Nothing
> Set objMOA = Server.CreateObject("MOA.Application")
> Set Application("MOA") = objMOA
>
> Il s'agit d'utiliser dans toute l'application, dans un espace commun à
> toutes les sessions une instance d'une DLL écrite en VB6. Ce code
> fonctionne
> parfaitement sous la plate-forme actuelle, mais sous la plate-forme cible,
> j'obtiens le message d'erreur suivant :
>
> Objet Application erreur 'ASP 0197 : 80004005'
>
> Utilisation d'objet non autorisée
>
> /LM/W3SVC/1/Root/Test/global.asa, ligne 22
>
> Seuls les objets dont le comportement est celui du modèle Apartment
> peuvent
> être ajoutés à l'objet intrinsèque de l'application.
>
>
> L'erreur intervient sur la ligne Set Application("MOA") = objMOA et ne se
> produit plus si elle est modifiée en Set Session("MOA") = objMOA.
>
> Comment obtenir les propriétés de partage d'une variable application sous
> IIS6 dans ce cas?
>
>
> Merci par avance de vos réponses.
>

Je n'en suis plus très sûr mais à mon avis, vous ne pouvez pas sans réécrire
ou recompiler le serveur COM MOA.Application. Le problème ici est que si le
serveur MOA.Application n'est pas de type Apartment, l'ajout d'un tel objet
sour IIS4 faisait automatiquement passer le mode de fonctionnement de IIS4
du modèle multi-thread vers le modèle single-thread; avec la sérieuse perte
de performance concomitante affectant *tous* les sites web situés sur ce
serveur. Avec IIS6, ce comportement a été banni.

Avec IIS, il est possible de déclarer un répertoire web comme étant une
application (isolée des autres applications et de l'application de base) et
de configurer ce répertoire avec des propriétés distinctes. Peut-être qu'en
regardant de ce côté-là, vous pourrez reconfigurer cette (sous-)application
web de façon à pouvoir stocker votre objet compilé sous ce modèle
particulier. C'est simplement une vague idée que je vous dis-là car c'est
le genre de chose que je n'ai plus regardé depuis plusieurs années.

La méthode moderne de partager de l'information entre plusieurs sessions est
tout simplement de stocker l'information dans une base de donnée. Toutes
les autres méthodes entrainent généralement une perte de performance; y
compris dans les cas où vous stockez un object de type Apartment (je ne suis
plus sûr de l'exact dénomination ici; les années ayant fait leur ravage)
puisque vous êtes alors dans la situation où un object potentiellement
inutilisé pendant de longues périodes (minutes, heures, jours, mois et même
années, décennies) occupe inutilement de la place en mémoire vide pendant
tout ce temps-là.

Même dans le cas de Session, MS décourageait l'utilisation de stockage
d'objets "stateful" et la méthode recommandée était d'avoir des objets de
type "stateless" managé par Transaction Server (avec l'information
permanente requise par ces "business objects" stockée dans une bdd).
Aujourd'hui, MS décourage tout simplement l'utilisation de COM dans tous les
cas de nouveau développement. Ce n'est pas pour rien que VB6 n'est plus
vendu par MS (et probablement qu'il va vous être difficile de trouver de la
documentation à ce sujet-là sur internet pour la même raison).

Finalement, comme ma mémoire a subi l'outrage des années, il est fort
possible que je vous ai donnée des renseignements plus ou moins faux dans ce
post; ayant moi-même pratiquement tout oublié à ce sujet-là. Si c'est le
cas, je m'en excuse d'avance mais je n'ai pas l'intention de commencer une
vive discussion ici ou d'entamer des recherches approfondies sur internet.
Pour moi, VB6 a été submergé dans les profondeurs du passé et ce n'est pas
là quelque chose que j'ai l'intention de ramener à la surface; mis-à-part
quelques vagues reflets sous-marins.

Dans votre cas, si vous n'êtes pas capable de résoudre ce problème soit en
reconfigurant IIS6, en recompilant MOA.Application sous un autre mode ou en
remplaçant MOA.Application par autre chose; la meilleure idée serait
peut-être tout simplement de conserver NT4; possiblement en le faisant
tourner dans une machine virtuelle.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Arthur" <Arthur***discussions.microsoft.com> wrote in message
news8973F42-6583-4ECD-92D7-6585DFC7457C***microsoft.com...
> Bonjour à tous,
>
> Je tente de porter une application ASP basée sur IIS4, NT4 et SQL Server 7
> vers une plate-forme IIS6, Windows 20003 et SQL Server 2000.
>
> Dans le global.asa, dans Application_OnStart se trouve le code suivant :
>
> Set ObjMoa = Nothing
> Set Application("MOA") = Nothing
> Set objMOA = Server.CreateObject("MOA.Application")
> Set Application("MOA") = objMOA
>
> Il s'agit d'utiliser dans toute l'application, dans un espace commun à
> toutes les sessions une instance d'une DLL écrite en VB6. Ce code
> fonctionne
> parfaitement sous la plate-forme actuelle, mais sous la plate-forme cible,
> j'obtiens le message d'erreur suivant :
>
> Objet Application erreur 'ASP 0197 : 80004005'
>
> Utilisation d'objet non autorisée
>
> /LM/W3SVC/1/Root/Test/global.asa, ligne 22
>
> Seuls les objets dont le comportement est celui du modèle Apartment
> peuvent
> être ajoutés à l'objet intrinsèque de l'application.
>
>
> L'erreur intervient sur la ligne Set Application("MOA") = objMOA et ne se
> produit plus si elle est modifiée en Set Session("MOA") = objMOA.
>
> Comment obtenir les propriétés de partage d'une variable application sous
> IIS6 dans ce cas?
>
>
> Merci par avance de vos réponses.
>