OVH Cloud OVH Cloud

Problème de deploiement site .net 2

2 réponses
Avatar
WT
Bonjour,

Voici le probleme: une application web net 1.1 utilisait le principe des
modules chargés par un moteur, a la façon DNN.
Pour ecrire un module, il siffisait de lui indiquer en reference l'assembly
du site principal (le moteur) et d'ecrire des classes qui heritaient de
classes de base situées dans le moteur.
Une API du moteur chargeait dynamiquement les modules et leurs assemblies
pour composer des pages.
Très difficile de reitérer cela avec .net 2: j'utilise un projet de
deploiement dans lequel je force la creation d'une seule assembly contenant
les pages et les controles pour le moteur.
Jusqu'à la pas de problème tout est Ok et j'obtient bien une seule assembly
qui fonctionne pour le site.
J'indique ensuite cette assembly comme reference d'un module monté ben
projet web indépendant, la compilation ne pose pas de problèmes.
Mais le deploiement avec un projet de deploiement identique.a celui du
moteur donne l'erreur suivante:
Error 1 Could not load type 'WT.Settings.DBDataStore' from assembly
'App_Code, Version=1.0.0.37368, Culture=neutral, PublicKeyToken=null'.
ASPNETCOMPILER 1 1 AdManager_deploy

Il apparait que l'outil de compression recherche la classe DBDataStore dans
la mauvaise assembly.
Cette classe est dans le moteur et non dans le module, or il la recherche
dans l'assembly App_Code du module.

Cela semble un bug ???

Je souligne que cela fonctionnait sans pb en 1.1
Comment porter ce processus en 2.0 ?

Merci par avance pour toute indication
CS

2 réponses

Avatar
Simon Mourier [SoftFluent]
Le type à charger dynamiquement est probablement mal renseigné. Apparemment,
la chaîne de caractère ne contient que le nom (complet avec namespace) de la
class (WT.Settings.DBDataStore). Il manque sans doute le nom de l'assembly.
Il faudrait donc spécifier (là où ça se fait dans l'application):

"WT.Settings.DBDataStore, <nom de l'assembly>"

à la place de

"WT.Settings.DBDataStore"

par exemple

WT.Settings.DBDataStore, MachinTruc
ou
WT.Settings.DBDataStore, MachinTruc, Version=2.0.0.0, Culture=neutral,
PublicKeyTokený65121322

car sinon, .NET va chercher dans l'assembly courante, si l'assembly
contenant WT.Settings.DBDataStore n'a pas encore été chargée dans
l'AppDomain.
Simon.
www.softfluent.com


"WT" a écrit dans le message de news:

Bonjour,

Voici le probleme: une application web net 1.1 utilisait le principe des
modules chargés par un moteur, a la façon DNN.
Pour ecrire un module, il siffisait de lui indiquer en reference
l'assembly du site principal (le moteur) et d'ecrire des classes qui
heritaient de classes de base situées dans le moteur.
Une API du moteur chargeait dynamiquement les modules et leurs assemblies
pour composer des pages.
Très difficile de reitérer cela avec .net 2: j'utilise un projet de
deploiement dans lequel je force la creation d'une seule assembly
contenant les pages et les controles pour le moteur.
Jusqu'à la pas de problème tout est Ok et j'obtient bien une seule
assembly qui fonctionne pour le site.
J'indique ensuite cette assembly comme reference d'un module monté ben
projet web indépendant, la compilation ne pose pas de problèmes.
Mais le deploiement avec un projet de deploiement identique.a celui du
moteur donne l'erreur suivante:
Error 1 Could not load type 'WT.Settings.DBDataStore' from assembly
'App_Code, Version=1.0.0.37368, Culture=neutral, PublicKeyToken=null'.
ASPNETCOMPILER 1 1 AdManager_deploy

Il apparait que l'outil de compression recherche la classe DBDataStore
dans la mauvaise assembly.
Cette classe est dans le moteur et non dans le module, or il la recherche
dans l'assembly App_Code du module.

Cela semble un bug ???

Je souligne que cela fonctionnait sans pb en 1.1
Comment porter ce processus en 2.0 ?

Merci par avance pour toute indication
CS



Avatar
WT
Merci Simon mais le problème intervient en deploiement du projet web, en
compilation en quelque sorte.
Ce n'est pas un pb d'execution
A est dans assembly A1
B herite de A dans projet B1 et utilise A1 comme reference.
Lors de la fabrication de B1, le compilateur cherche A dans App_Code de B1
et non dans A1.

Cela semble du au fait que A est dans App_Code de A1, aux dernières
nouvelles, il faut signer toutes les assemblies pour qu'il n'y ait pas de
confusion sur le App_Code d'origine des classes....

Cela me semble un pb ASP.NET 2.
On ne peut utiliser en reference d'un site web l'assembly issue d'un autre
projet Web, alors que c'était possible en 1.1.

CS

"Simon Mourier [SoftFluent]" a écrit dans le
message de news:
Le type à charger dynamiquement est probablement mal renseigné.
Apparemment, la chaîne de caractère ne contient que le nom (complet avec
namespace) de la class (WT.Settings.DBDataStore). Il manque sans doute le
nom de l'assembly. Il faudrait donc spécifier (là où ça se fait dans
l'application):

"WT.Settings.DBDataStore, <nom de l'assembly>"

à la place de

"WT.Settings.DBDataStore"

par exemple

WT.Settings.DBDataStore, MachinTruc
ou
WT.Settings.DBDataStore, MachinTruc, Version=2.0.0.0, Culture=neutral,
PublicKeyTokený65121322

car sinon, .NET va chercher dans l'assembly courante, si l'assembly
contenant WT.Settings.DBDataStore n'a pas encore été chargée dans
l'AppDomain.
Simon.
www.softfluent.com


"WT" a écrit dans le message de news:

Bonjour,

Voici le probleme: une application web net 1.1 utilisait le principe des
modules chargés par un moteur, a la façon DNN.
Pour ecrire un module, il siffisait de lui indiquer en reference
l'assembly du site principal (le moteur) et d'ecrire des classes qui
heritaient de classes de base situées dans le moteur.
Une API du moteur chargeait dynamiquement les modules et leurs assemblies
pour composer des pages.
Très difficile de reitérer cela avec .net 2: j'utilise un projet de
deploiement dans lequel je force la creation d'une seule assembly
contenant les pages et les controles pour le moteur.
Jusqu'à la pas de problème tout est Ok et j'obtient bien une seule
assembly qui fonctionne pour le site.
J'indique ensuite cette assembly comme reference d'un module monté ben
projet web indépendant, la compilation ne pose pas de problèmes.
Mais le deploiement avec un projet de deploiement identique.a celui du
moteur donne l'erreur suivante:
Error 1 Could not load type 'WT.Settings.DBDataStore' from assembly
'App_Code, Version=1.0.0.37368, Culture=neutral, PublicKeyToken=null'.
ASPNETCOMPILER 1 1 AdManager_deploy

Il apparait que l'outil de compression recherche la classe DBDataStore
dans la mauvaise assembly.
Cette classe est dans le moteur et non dans le module, or il la recherche
dans l'assembly App_Code du module.

Cela semble un bug ???

Je souligne que cela fonctionnait sans pb en 1.1
Comment porter ce processus en 2.0 ?

Merci par avance pour toute indication
CS