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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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" <WT@newsgroups.nospam> a écrit dans le message de news:
eHBgomaeGHA.1272@TK2MSFTNGP03.phx.gbl...
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 ?
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
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
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]" <simon.mourier@mycompany.com> a écrit dans le
message de news: e6UBqdkeGHA.2188@TK2MSFTNGP04.phx.gbl...
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" <WT@newsgroups.nospam> a écrit dans le message de news:
eHBgomaeGHA.1272@TK2MSFTNGP03.phx.gbl...
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 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 ?