J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les
Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces
de noms. Doit on les positionner dans un répertoire spécifique avant
compilation ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
Patrice
/r permet de référencer les DLLs, /imports permet de préciser les espaces de noms à importer (et VS.NET permet de spécifier des imports globalement pour le projet qui sont donc à reprendre lorsque tu compiles en ligne de commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une DLL pour ton site web dans le répertoire /bin (je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" a écrit dans le message de news:
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
/r permet de référencer les DLLs, /imports permet de préciser les espaces de
noms à importer (et VS.NET permet de spécifier des imports globalement pour
le projet qui sont donc à reprendre lorsque tu compiles en ligne de
commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une DLL
pour ton site web dans le répertoire /bin
(je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" <emouchet@test.com> a écrit dans le message de
news:efEMti3aFHA.3848@TK2MSFTNGP10.phx.gbl...
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les
Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces
de noms. Doit on les positionner dans un répertoire spécifique avant
compilation ?
/r permet de référencer les DLLs, /imports permet de préciser les espaces de noms à importer (et VS.NET permet de spécifier des imports globalement pour le projet qui sont donc à reprendre lorsque tu compiles en ligne de commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une DLL pour ton site web dans le répertoire /bin (je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" a écrit dans le message de news:
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
Fabrice
Encore moi Patrice Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
/r permet de référencer les DLLs, /imports permet de préciser les espaces de noms à importer (et VS.NET permet de spécifier des imports globalement pour le projet qui sont donc à reprendre lorsque tu compiles en ligne de commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une DLL pour ton site web dans le répertoire /bin (je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" a écrit dans le message de news:
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
Encore moi Patrice
Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver.
Donc je dois constituer le conde behind à la main et aussi compiler à la
main.
Je voulais simplement vérifier que la compilation se passait bien.
Pour l'instant pas trop.
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
eFUCK43aFHA.2664@TK2MSFTNGP15.phx.gbl...
/r permet de référencer les DLLs, /imports permet de préciser les espaces
de
noms à importer (et VS.NET permet de spécifier des imports globalement
pour
le projet qui sont donc à reprendre lorsque tu compiles en ligne de
commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une
DLL
pour ton site web dans le répertoire /bin
(je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" <emouchet@test.com> a écrit dans le message de
news:efEMti3aFHA.3848@TK2MSFTNGP10.phx.gbl...
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les
Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les
espaces
de noms. Doit on les positionner dans un répertoire spécifique avant
compilation ?
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
/r permet de référencer les DLLs, /imports permet de préciser les espaces de noms à importer (et VS.NET permet de spécifier des imports globalement pour le projet qui sont donc à reprendre lorsque tu compiles en ligne de commande).
Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une DLL pour ton site web dans le répertoire /bin (je l'ai utilisé pour créer de multiples DLLs).
Patrice
--
"fabrice" a écrit dans le message de news:
j'ai oublié une précision
doit on préciser dans la ligne de commande de compilation tous les Namespaces importés ?
J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les espaces de noms. Doit on les positionner dans un répertoire spécifique avant compilation ?
merci
Patrice
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent correctement" que cela marchait et que tu essayais ensuite de compiler le code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet à priori de faire du "code behind" qui sera compilé avec la page ASPX lorsque celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à compiler explicitement (au moins pendant que le code est mis au point)...
-- Patrice
"Fabrice" a écrit dans le message de news:
Encore moi Patrice Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de > noms à importer (et VS.NET permet de spécifier des imports globalement > pour > le projet qui sont donc à reprendre lorsque tu compiles en ligne de > commande). > > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une > DLL > pour ton site web dans le répertoire /bin > (je l'ai utilisé pour créer de multiples DLLs). > > Patrice > > -- > > "fabrice" a écrit dans le message de > news: >> j'ai oublié une précision >> >> doit on préciser dans la ligne de commande de compilation tous les >> Namespaces importés ? >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> /r:System.data..../r:System.Data.OleDb >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> espaces >> de noms. Doit on les positionner dans un répertoire spécifique avant >> compilation ? >> >> merci >> >> > >
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent
correctement" que cela marchait et que tu essayais ensuite de compiler le
code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet à
priori de faire du "code behind" qui sera compilé avec la page ASPX lorsque
celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à
compiler explicitement (au moins pendant que le code est mis au point)...
--
Patrice
"Fabrice" <emouchet@spam-infonie.fr> a écrit dans le message de
news:OPJfu3FbFHA.3120@TK2MSFTNGP12.phx.gbl...
Encore moi Patrice
Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver.
Donc je dois constituer le conde behind à la main et aussi compiler à la
main.
Je voulais simplement vérifier que la compilation se passait bien.
Pour l'instant pas trop.
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
eFUCK43aFHA.2664@TK2MSFTNGP15.phx.gbl...
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de
> noms à importer (et VS.NET permet de spécifier des imports globalement
> pour
> le projet qui sont donc à reprendre lorsque tu compiles en ligne de
> commande).
>
> Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une
> DLL
> pour ton site web dans le répertoire /bin
> (je l'ai utilisé pour créer de multiples DLLs).
>
> Patrice
>
> --
>
> "fabrice" <emouchet@test.com> a écrit dans le message de
> news:efEMti3aFHA.3848@TK2MSFTNGP10.phx.gbl...
>> j'ai oublié une précision
>>
>> doit on préciser dans la ligne de commande de compilation tous les
>> Namespaces importés ?
>>
>> vbc .. /t:library monfichier.aspx.vb /r:Imports System,
>> /r:System.data..../r:System.Data.OleDb
>>
>> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les
>> espaces
>> de noms. Doit on les positionner dans un répertoire spécifique avant
>> compilation ?
>>
>> merci
>>
>>
>
>
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent correctement" que cela marchait et que tu essayais ensuite de compiler le code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet à priori de faire du "code behind" qui sera compilé avec la page ASPX lorsque celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à compiler explicitement (au moins pendant que le code est mis au point)...
-- Patrice
"Fabrice" a écrit dans le message de news:
Encore moi Patrice Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de > noms à importer (et VS.NET permet de spécifier des imports globalement > pour > le projet qui sont donc à reprendre lorsque tu compiles en ligne de > commande). > > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une > DLL > pour ton site web dans le répertoire /bin > (je l'ai utilisé pour créer de multiples DLLs). > > Patrice > > -- > > "fabrice" a écrit dans le message de > news: >> j'ai oublié une précision >> >> doit on préciser dans la ligne de commande de compilation tous les >> Namespaces importés ? >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> /r:System.data..../r:System.Data.OleDb >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> espaces >> de noms. Doit on les positionner dans un répertoire spécifique avant >> compilation ? >> >> merci >> >> > >
fabrice
Hello Patrice,
Mes pages sont en code behind. Avec un appel du type : <%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je n'ai aucun souci de fonctionnement. Je veux compiller mes .vb en .dll pour une protection des sources. JE faisais donc un essai. Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour moi. Comme mes pages ne se plantent pas et que la compilation à la volée passe je me dis que le code n est pas en cause. Plutot la méthode de compilation manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci fab
"Patrice" a écrit dans le message de news:
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent correctement" que cela marchait et que tu essayais ensuite de compiler le code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet à priori de faire du "code behind" qui sera compilé avec la page ASPX lorsque celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à compiler explicitement (au moins pendant que le code est mis au point)...
-- Patrice
"Fabrice" a écrit dans le message de news:
Encore moi Patrice Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de > noms à importer (et VS.NET permet de spécifier des imports globalement > pour > le projet qui sont donc à reprendre lorsque tu compiles en ligne de > commande). > > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une > DLL > pour ton site web dans le répertoire /bin > (je l'ai utilisé pour créer de multiples DLLs). > > Patrice > > -- > > "fabrice" a écrit dans le message de > news: >> j'ai oublié une précision >> >> doit on préciser dans la ligne de commande de compilation tous les >> Namespaces importés ? >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> /r:System.data..../r:System.Data.OleDb >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> espaces >> de noms. Doit on les positionner dans un répertoire spécifique avant >> compilation ? >> >> merci >> >> > >
Hello Patrice,
Mes pages sont en code behind. Avec un appel du type :
<%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je n'ai
aucun souci de fonctionnement.
Je veux compiller mes .vb en .dll pour une protection des sources. JE
faisais donc un essai.
Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour
moi. Comme mes pages ne se plantent pas et que la compilation à la volée
passe
je me dis que le code n est pas en cause. Plutot la méthode de compilation
manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci
fab
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
e87lpXNbFHA.616@TK2MSFTNGP12.phx.gbl...
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent
correctement" que cela marchait et que tu essayais ensuite de compiler le
code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet
à
priori de faire du "code behind" qui sera compilé avec la page ASPX
lorsque
celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à
compiler explicitement (au moins pendant que le code est mis au point)...
--
Patrice
"Fabrice" <emouchet@spam-infonie.fr> a écrit dans le message de
news:OPJfu3FbFHA.3120@TK2MSFTNGP12.phx.gbl...
Encore moi Patrice
Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver.
Donc je dois constituer le conde behind à la main et aussi compiler à la
main.
Je voulais simplement vérifier que la compilation se passait bien.
Pour l'instant pas trop.
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
eFUCK43aFHA.2664@TK2MSFTNGP15.phx.gbl...
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de
> noms à importer (et VS.NET permet de spécifier des imports globalement
> pour
> le projet qui sont donc à reprendre lorsque tu compiles en ligne de
> commande).
>
> Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une
> DLL
> pour ton site web dans le répertoire /bin
> (je l'ai utilisé pour créer de multiples DLLs).
>
> Patrice
>
> --
>
> "fabrice" <emouchet@test.com> a écrit dans le message de
> news:efEMti3aFHA.3848@TK2MSFTNGP10.phx.gbl...
>> j'ai oublié une précision
>>
>> doit on préciser dans la ligne de commande de compilation tous les
>> Namespaces importés ?
>>
>> vbc .. /t:library monfichier.aspx.vb /r:Imports System,
>> /r:System.data..../r:System.Data.OleDb
>>
>> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les
>> espaces
>> de noms. Doit on les positionner dans un répertoire spécifique avant
>> compilation ?
>>
>> merci
>>
>>
>
>
Mes pages sont en code behind. Avec un appel du type : <%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je n'ai aucun souci de fonctionnement. Je veux compiller mes .vb en .dll pour une protection des sources. JE faisais donc un essai. Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour moi. Comme mes pages ne se plantent pas et que la compilation à la volée passe je me dis que le code n est pas en cause. Plutot la méthode de compilation manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci fab
"Patrice" a écrit dans le message de news:
Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent correctement" que cela marchait et que tu essayais ensuite de compiler le code autrement...
Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut permet à priori de faire du "code behind" qui sera compilé avec la page ASPX lorsque celle ci est appelée...
Cela pourrait être une façon de garder deux fichiers séparés sans avoir à compiler explicitement (au moins pendant que le code est mis au point)...
-- Patrice
"Fabrice" a écrit dans le message de news:
Encore moi Patrice Je te réponds un peu tard.
Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. Donc je dois constituer le conde behind à la main et aussi compiler à la main.
Je voulais simplement vérifier que la compilation se passait bien. Pour l'instant pas trop.
"Patrice" a écrit dans le message de news:
> /r permet de référencer les DLLs, /imports permet de préciser les
espaces
> de > noms à importer (et VS.NET permet de spécifier des imports globalement > pour > le projet qui sont donc à reprendre lorsque tu compiles en ligne de > commande). > > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé une > DLL > pour ton site web dans le répertoire /bin > (je l'ai utilisé pour créer de multiples DLLs). > > Patrice > > -- > > "fabrice" a écrit dans le message de > news: >> j'ai oublié une précision >> >> doit on préciser dans la ligne de commande de compilation tous les >> Namespaces importés ? >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> /r:System.data..../r:System.Data.OleDb >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> espaces >> de noms. Doit on les positionner dans un répertoire spécifique avant >> compilation ? >> >> merci >> >> > >
Patrick Philippot
Bonjour,
Vous avez posé la même question sur fr.dotnet. Est-ce que ma réponse est à côté de la plaque ou bien résout-elle le problème ?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Vous avez posé la même question sur fr.dotnet. Est-ce que ma réponse est
à côté de la plaque ou bien résout-elle le problème ?
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Vous avez posé la même question sur fr.dotnet. Est-ce que ma réponse est à côté de la plaque ou bien résout-elle le problème ?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrice
Il y a effectivement une option /recurse qui permet de traiter tous les fichiers y compris dans les sous-répertoires. Il peut y avoir aussi des problèmes liés au fait que le contexte est un peu différent selon que la compilation se fait fichier par fichier ou comme peut-être tu essaies ici globalement...
Le mieux est de voir quel est l'erreur de compilation que tu as actuellement et de voir de là si ecela peut-être une otpion manquante....
A+ --
"fabrice" a écrit dans le message de news:
Hello Patrice,
Mes pages sont en code behind. Avec un appel du type : <%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je
n'ai
aucun souci de fonctionnement. Je veux compiller mes .vb en .dll pour une protection des sources. JE faisais donc un essai. Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour moi. Comme mes pages ne se plantent pas et que la compilation à la volée passe je me dis que le code n est pas en cause. Plutot la méthode de compilation manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci fab
"Patrice" a écrit dans le message de news:
> Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent > correctement" que cela marchait et que tu essayais ensuite de compiler
le
> code autrement... > > Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut
permet
> à > priori de faire du "code behind" qui sera compilé avec la page ASPX > lorsque > celle ci est appelée... > > Cela pourrait être une façon de garder deux fichiers séparés sans avoir
à
> compiler explicitement (au moins pendant que le code est mis au
point)...
> > -- > Patrice > > "Fabrice" a écrit dans le message de > news: >> Encore moi Patrice >> Je te réponds un peu tard. >> >> Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. >> Donc je dois constituer le conde behind à la main et aussi compiler à
la
>> main. >> >> Je voulais simplement vérifier que la compilation se passait bien. >> Pour l'instant pas trop. >> >> >> "Patrice" a écrit dans le message de news: >> >> > /r permet de référencer les DLLs, /imports permet de préciser les > espaces >> > de >> > noms à importer (et VS.NET permet de spécifier des imports
globalement
>> > pour >> > le projet qui sont donc à reprendre lorsque tu compiles en ligne de >> > commande). >> > >> > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé
une
>> > DLL >> > pour ton site web dans le répertoire /bin >> > (je l'ai utilisé pour créer de multiples DLLs). >> > >> > Patrice >> > >> > -- >> > >> > "fabrice" a écrit dans le message de >> > news: >> >> j'ai oublié une précision >> >> >> >> doit on préciser dans la ligne de commande de compilation tous les >> >> Namespaces importés ? >> >> >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> >> /r:System.data..../r:System.Data.OleDb >> >> >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> >> espaces >> >> de noms. Doit on les positionner dans un répertoire spécifique avant >> >> compilation ? >> >> >> >> merci >> >> >> >> >> > >> > >> >> > >
Il y a effectivement une option /recurse qui permet de traiter tous les
fichiers y compris dans les sous-répertoires. Il peut y avoir aussi des
problèmes liés au fait que le contexte est un peu différent selon que la
compilation se fait fichier par fichier ou comme peut-être tu essaies ici
globalement...
Le mieux est de voir quel est l'erreur de compilation que tu as actuellement
et de voir de là si ecela peut-être une otpion manquante....
A+
--
"fabrice" <emouchet@test.com> a écrit dans le message de
news:u0QlWDQbFHA.2736@TK2MSFTNGP12.phx.gbl...
Hello Patrice,
Mes pages sont en code behind. Avec un appel du type :
<%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je
n'ai
aucun souci de fonctionnement.
Je veux compiller mes .vb en .dll pour une protection des sources. JE
faisais donc un essai.
Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour
moi. Comme mes pages ne se plantent pas et que la compilation à la volée
passe
je me dis que le code n est pas en cause. Plutot la méthode de compilation
manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci
fab
"Patrice" <nobody@nowhere.com> a écrit dans le message de news:
e87lpXNbFHA.616@TK2MSFTNGP12.phx.gbl...
> Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent
> correctement" que cela marchait et que tu essayais ensuite de compiler
le
> code autrement...
>
> Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut
permet
> à
> priori de faire du "code behind" qui sera compilé avec la page ASPX
> lorsque
> celle ci est appelée...
>
> Cela pourrait être une façon de garder deux fichiers séparés sans avoir
à
> compiler explicitement (au moins pendant que le code est mis au
point)...
>
> --
> Patrice
>
> "Fabrice" <emouchet@spam-infonie.fr> a écrit dans le message de
> news:OPJfu3FbFHA.3120@TK2MSFTNGP12.phx.gbl...
>> Encore moi Patrice
>> Je te réponds un peu tard.
>>
>> Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver.
>> Donc je dois constituer le conde behind à la main et aussi compiler à
la
>> main.
>>
>> Je voulais simplement vérifier que la compilation se passait bien.
>> Pour l'instant pas trop.
>>
>>
>> "Patrice" <nobody@nowhere.com> a écrit dans le message de news:
>> eFUCK43aFHA.2664@TK2MSFTNGP15.phx.gbl...
>> > /r permet de référencer les DLLs, /imports permet de préciser les
> espaces
>> > de
>> > noms à importer (et VS.NET permet de spécifier des imports
globalement
>> > pour
>> > le projet qui sont donc à reprendre lorsque tu compiles en ligne de
>> > commande).
>> >
>> > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé
une
>> > DLL
>> > pour ton site web dans le répertoire /bin
>> > (je l'ai utilisé pour créer de multiples DLLs).
>> >
>> > Patrice
>> >
>> > --
>> >
>> > "fabrice" <emouchet@test.com> a écrit dans le message de
>> > news:efEMti3aFHA.3848@TK2MSFTNGP10.phx.gbl...
>> >> j'ai oublié une précision
>> >>
>> >> doit on préciser dans la ligne de commande de compilation tous les
>> >> Namespaces importés ?
>> >>
>> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System,
>> >> /r:System.data..../r:System.Data.OleDb
>> >>
>> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les
>> >> espaces
>> >> de noms. Doit on les positionner dans un répertoire spécifique avant
>> >> compilation ?
>> >>
>> >> merci
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Il y a effectivement une option /recurse qui permet de traiter tous les fichiers y compris dans les sous-répertoires. Il peut y avoir aussi des problèmes liés au fait que le contexte est un peu différent selon que la compilation se fait fichier par fichier ou comme peut-être tu essaies ici globalement...
Le mieux est de voir quel est l'erreur de compilation que tu as actuellement et de voir de là si ecela peut-être une otpion manquante....
A+ --
"fabrice" a écrit dans le message de news:
Hello Patrice,
Mes pages sont en code behind. Avec un appel du type : <%@Page language="vb" inherits="MyClass" src="/orbehind/mapage.aspx.vb" %>
La page est donc compilée au moment de l'appel du fichier .aspx. Et je
n'ai
aucun souci de fonctionnement. Je veux compiller mes .vb en .dll pour une protection des sources. JE faisais donc un essai. Je cherche simplement la bonne syntaxe. Mais jusque la pas terrible pour moi. Comme mes pages ne se plantent pas et que la compilation à la volée passe je me dis que le code n est pas en cause. Plutot la méthode de compilation manuelle.
Dois je notamment compiler mes .vb depuis le WebRoot ?
merci fab
"Patrice" a écrit dans le message de news:
> Tiens quel hasard ;-) Ok je croyais à cause du "les pages fonctionnent > correctement" que cela marchait et que tu essayais ensuite de compiler
le
> code autrement... > > Essaie de remplacer l'attribut "codebehind" par "src". Cet attribut
permet
> à > priori de faire du "code behind" qui sera compilé avec la page ASPX > lorsque > celle ci est appelée... > > Cela pourrait être une façon de garder deux fichiers séparés sans avoir
à
> compiler explicitement (au moins pendant que le code est mis au
point)...
> > -- > Patrice > > "Fabrice" a écrit dans le message de > news: >> Encore moi Patrice >> Je te réponds un peu tard. >> >> Je n'utilise pas VS. Un peu WebMatrix et DreamWeaver. >> Donc je dois constituer le conde behind à la main et aussi compiler à
la
>> main. >> >> Je voulais simplement vérifier que la compilation se passait bien. >> Pour l'instant pas trop. >> >> >> "Patrice" a écrit dans le message de news: >> >> > /r permet de référencer les DLLs, /imports permet de préciser les > espaces >> > de >> > noms à importer (et VS.NET permet de spécifier des imports
globalement
>> > pour >> > le projet qui sont donc à reprendre lorsque tu compiles en ligne de >> > commande). >> > >> > Pourquoi utiliser le compilateur en ligne de commande ? VS.NET créé
une
>> > DLL >> > pour ton site web dans le répertoire /bin >> > (je l'ai utilisé pour créer de multiples DLLs). >> > >> > Patrice >> > >> > -- >> > >> > "fabrice" a écrit dans le message de >> > news: >> >> j'ai oublié une précision >> >> >> >> doit on préciser dans la ligne de commande de compilation tous les >> >> Namespaces importés ? >> >> >> >> vbc .. /t:library monfichier.aspx.vb /r:Imports System, >> >> /r:System.data..../r:System.Data.OleDb >> >> >> >> J'ai essayé mais j'ai des messages comme quoi il ne toruve pas les >> >> espaces >> >> de noms. Doit on les positionner dans un répertoire spécifique avant >> >> compilation ? >> >> >> >> merci >> >> >> >> >> > >> > >> >> > >
fabrice
Bonjour Patrick
Je suis désolé, j'ai pris connaissance tardivement de la réponse. En tout cas elle m'a été d'une grande aide. Je faisais effectivement une confusion. J'ai effectivement besoin de faire référence aux Assembly que j'utilise. Par exemple pour l'import du Namespace system.data.oledb je dois faire référence à l'assembly System.Data.dll. Si j'ai bien compris je suis dans l'obligation d'identifier tous les Assemblys dont j'ai besoin et de les intégrer dans ma commande de compilation.
en tout cas, désolé encore pour mon manque de réaction et merci de ta réponse.
à bientôt fabrice
"Patrick Philippot" a écrit dans le message de news:
Bonjour,
Vous avez posé la même question sur fr.dotnet. Est-ce que ma réponse est à côté de la plaque ou bien résout-elle le problème ?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour Patrick
Je suis désolé, j'ai pris connaissance tardivement de la réponse. En tout
cas elle m'a été d'une grande aide.
Je faisais effectivement une confusion.
J'ai effectivement besoin de faire référence aux Assembly que j'utilise. Par
exemple pour l'import du Namespace system.data.oledb je dois faire référence
à l'assembly
System.Data.dll. Si j'ai bien compris je suis dans l'obligation d'identifier
tous les Assemblys dont j'ai besoin et de les intégrer dans ma commande de
compilation.
Je suis désolé, j'ai pris connaissance tardivement de la réponse. En tout cas elle m'a été d'une grande aide. Je faisais effectivement une confusion. J'ai effectivement besoin de faire référence aux Assembly que j'utilise. Par exemple pour l'import du Namespace system.data.oledb je dois faire référence à l'assembly System.Data.dll. Si j'ai bien compris je suis dans l'obligation d'identifier tous les Assemblys dont j'ai besoin et de les intégrer dans ma commande de compilation.
