DataSets qui ne supportent pas le voyage
Gloops
Dans un site web, j'ai deux DataSets qui fonctionnent très bien sous
Visual Studio, pour brancher sur une base MySql installée sur ma machine.
Une fois le site déployé sur le serveur, voici le topo (à l'affichage
d'une page qui fait appel au DataSet) :
=========== Début de topo ====================
Parser Error
Description: An error occurred during the parsing of a resource required
to service this request. Please review the following specific parse
error details and modify your source file appropriately.
Parser Error Message: Failed to generate code. Exception of type
'System.Data.Design.InternalException' was thrown.
Source Error:
Line 1: <?xml version="1.0" encoding="utf-8"?>
Line 2: <xs:schema id="DataSet1"
(et patati et patata, mais c'est la première ligne qui est en rouge)
Source File: /App_Code/DataSet1.xsd Line: 1
=========== Fin de topo ====================
Alors je regarde là :
http://forums.asp.net/t/1011934.aspx
et je vois que le dataset pointe sur une source non valide, car en effet
le chemin vers la base sur la machine de développement n'est pas valide
sur le serveur.
Seulement voilà, le chemin indiqué dans le fichier xsd se réfère à une
chaîne de connexion dans le web.config, qui lui a été mis à jour.
Comment y a-t-il lieu de procéder pour que le DataSet soit valide sur le
serveur ?
(A noter que la base sur le serveur ne peut pas être accédée depuis
Visual Studio).
C'est vrai qu'on aurait bien vu afficher comme erreur le chemin de la
base, bon enfin une fois qu'on sait ...
Gloops
Dans l'un des fichiers xsd, je trouve ça :
<xs:appinfo source="urn:schemas-microsoft-com:xml-msdatasource">
<DataSource DefaultConnectionIndex="0"
FunctionsComponentName="QueriesTableAdapter" Modifier="AutoLayout,
AnsiClass, Class, Public"
xmlns="urn:schemas-microsoft-com:xml-msdatasource">
<Connections>
<Connection AppSettingsObjectName="Web.config"
AppSettingsPropertyName="bas_site1ConnectionString"
ConnectionStringObject=""
IsAppSettingsProperty="True" Modifier="Assembly"
Name="bas_site1ConnectionString (Web.config)"
ParameterPrefix="@"
PropertyReference="AppConfig.System.Configuration.ConfigurationManager.0.ConnectionStrings.bas_site1ConnectionString.ConnectionString"
Provider="MySql.Data.MySqlClient">
</Connection>
</Connections>
L'attribut ParameterPrefix est souligné en rouge sous Visual Studio en
mode xml, là-dessus l'infobulle annonce "The 'ParameterPrefix' attribute
is not declared".
Ce n'est pourtant pas quelque chose que j'ai inventé, c'est l'assistant
Visual Studio qui a placé cet attribut.
Il y en a un certain nombre, comme ça, sur lesquels l'Intellisense n'est
pas d'accord avec l'assistant.
J'espère que le serveur n'a pas, lui, une troisième version ...
Par ailleurs en voyant DefaultConnectionIndex je me suis dit que l'ordre
de déclaration pouvait avoir une importance, surtout quand juste en
dessous je vois ConfigurationManager.0
Alors j'ai repris le web.config de développement pour le mettre sur le
serveur, puis corrigé la chaîne de connexion. Ensuite j'ai corrigé la
section customErrors, puis j'ai mis en commentaire la référence à
Windows.Forms, qui induit une erreur et qui a effectivement un certain
caractère incongru sur un site web, il faut que je me rappelle pourquoi
ça a été mis là.
Seulement voilà, mon DataSet n'est toujours pas reconnu. J'ai toujours
l'erreur "Parser Error Message: Failed to generate code. Exception of
type 'System.Data.Design.InternalException' was thrown."
_____________________________________
Gloops
de structure entre les bases de la machine de développement et du
serveur (d'ailleurs c'est vrai que j'ai changé la taille d'un champ en
cours de route), alors sur la machine de développement j'ai tapé SHOW
CREATE TABLE suivi du nom de la table, c'est une commande MySql qui me
donne la commande SQL de création de la table, puis sur l'interface
d'administration du serveur j'ai supprimé la table et je l'ai recréée
avec la commande SQL.
Pas de progrès.
Gloops
Visual Studio ce qui lui permet d'obtenir des erreurs détaillées par
champ. Malgré cela, il n'a pas trouvé, semble-t-il, depuis le mois d'Avril.