je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus
où) que l'ont pouvais compiler le code et mettre cette compilation sur le
serveur pour faire tourner le site/application
cela m'intéressent très fort pour protéger les sources du code
pouvez vous me dire ou avoir plus d'info sur se sujet ?
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus où) que l'ont pouvais compiler le code et mettre cette compilation sur le serveur pour faire tourner le site/application
Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
Bonjour,
James_Ptg wrote:
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais
plus où) que l'ont pouvais compiler le code et mettre cette
compilation sur le serveur pour faire tourner le site/application
Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même
temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
--
Christophe Lauer - Relations Techniques Editeurs de Logiciels
Division Développeurs et Plateforme d'Entreprise - Microsoft France
http://www.microsoft.com/france/msdn/
This posting is provided "AS IS" with no warranties, and confers no
rights.
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus où) que l'ont pouvais compiler le code et mettre cette compilation sur le serveur pour faire tourner le site/application
Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
Messenger of the red snake mountain
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans vsnet ?
Antonio
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même
temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans
vsnet ?
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même temps que Visual Studio 2005 et le .NET Framework 2.0.
Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans vsnet ?
Antonio
Patrice
En ASP.NET, le code-behind est effectivement compilé sous forme d'une DLL présente dans le répertoire /bin du site. Il est sans doute conseillé de passer un coup de "dotsfucator" dessus. Le but est de rendre plus difficile à comprendre le résultat d'une éventuelle décompilation...
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Patrice
--
"James_Ptg" a écrit dans le message de news:eCWgcY$
Hello people,
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus où) que l'ont pouvais compiler le code et mettre cette compilation sur le serveur pour faire tourner le site/application
cela m'intéressent très fort pour protéger les sources du code
pouvez vous me dire ou avoir plus d'info sur se sujet ?
D'avance merci à tous
En ASP.NET, le code-behind est effectivement compilé sous forme d'une DLL
présente dans le répertoire /bin du site. Il est sans doute conseillé de
passer un coup de "dotsfucator" dessus. Le but est de rendre plus difficile
à comprendre le résultat d'une éventuelle décompilation...
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris
les pages ASPX, les images etc... !!!)
Patrice
--
"James_Ptg" <Twinsen24@hotmail.Com> a écrit dans le message de
news:eCWgcY$TFHA.3652@TK2MSFTNGP10.phx.gbl...
Hello people,
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus
où) que l'ont pouvais compiler le code et mettre cette compilation sur le
serveur pour faire tourner le site/application
cela m'intéressent très fort pour protéger les sources du code
pouvez vous me dire ou avoir plus d'info sur se sujet ?
En ASP.NET, le code-behind est effectivement compilé sous forme d'une DLL présente dans le répertoire /bin du site. Il est sans doute conseillé de passer un coup de "dotsfucator" dessus. Le but est de rendre plus difficile à comprendre le résultat d'une éventuelle décompilation...
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Patrice
--
"James_Ptg" a écrit dans le message de news:eCWgcY$
Hello people,
je début en aspx (avant je dev. sous ASP3) et j'ai lus (mais je sais plus où) que l'ont pouvais compiler le code et mettre cette compilation sur le serveur pour faire tourner le site/application
cela m'intéressent très fort pour protéger les sources du code
pouvez vous me dire ou avoir plus d'info sur se sujet ?
D'avance merci à tous
Cyril S.
Bien possible !
Pour faire simple, le problème étant la protection des codes source lorsqu'on est éditeur de sites web (et oui c'est embétant que les clients puissent voir les sources).
Dans le Framework 1.1.
Dans une application ASP.NET 1.1, si tu as une page qui s'appele Default tu as : - d'un coté la partie HTML contenue dans le fichier Default.aspx - de l'autre la partie code (C#/VB.NET) contenue dans le fichier Default.aspx.cs.
Lorsque tu compiles ton projet sous Visual Studio, ton fichier Default.aspx.cs va être compilé dans une assembly (présente dans le rep /bin).
Lorsque tu déploies ton projet web, il te suffit de copier : - le fichier Default.aspx (et d'une manière générale tous les fichiers aspx, ascx et asmx) - le répertoire /bin qui contient le code compilé.
Donc tu n'as AUCUN fichier sources lors du déploiement ! Pour bien les choses, il te faudra en plus utiliser un outil "ofuscator" qui permet de masquer le code dans l'assembly (car il reste décompilable par reflexion .. cf un autre outil Reflector)
Le soucis c'est que les fichiers ASPX, ASXM et autres sont encore visibles et donc tu as peux protéger le code source mais pas les fichiers aspx.
Dans la version 2.0
Le mode de compilation a totalement changé, mais ce qui est intéressant c'est qu'il est possible de pré-compiler le site. La précompilation fait que TOUT le code C#/VB.NET/HTML/Javascript est intégré dans des assemblies.
Donc meme le code des fichiers ASPX n'est plus visible (les fichiers sont quand meme présent mais ils sont vides).
Bref la version 2.0 apporte une bonne solution pour ce genre de problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
------------------- CS
"Messenger of the red snake mountain" wrote:
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même > temps que Visual Studio 2005 et le .NET Framework 2.0. > > Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans vsnet ?
Antonio
Bien possible !
Pour faire simple, le problème étant la protection des codes source
lorsqu'on est éditeur de sites web (et oui c'est embétant que les clients
puissent voir les sources).
Dans le Framework 1.1.
Dans une application ASP.NET 1.1, si tu as une page qui s'appele Default tu
as :
- d'un coté la partie HTML contenue dans le fichier Default.aspx
- de l'autre la partie code (C#/VB.NET) contenue dans le fichier
Default.aspx.cs.
Lorsque tu compiles ton projet sous Visual Studio, ton fichier
Default.aspx.cs va être compilé dans une assembly (présente dans le rep
/bin).
Lorsque tu déploies ton projet web, il te suffit de copier :
- le fichier Default.aspx (et d'une manière générale tous les fichiers
aspx, ascx et asmx)
- le répertoire /bin qui contient le code compilé.
Donc tu n'as AUCUN fichier sources lors du déploiement ! Pour bien les
choses, il te faudra en plus utiliser un outil "ofuscator" qui permet de
masquer le code dans l'assembly (car il reste décompilable par reflexion ..
cf un autre outil Reflector)
Le soucis c'est que les fichiers ASPX, ASXM et autres sont encore visibles
et donc tu as peux protéger le code source mais pas les fichiers aspx.
Dans la version 2.0
Le mode de compilation a totalement changé, mais ce qui est intéressant
c'est qu'il est possible de pré-compiler le site. La précompilation fait que
TOUT le code C#/VB.NET/HTML/Javascript est intégré dans des assemblies.
Donc meme le code des fichiers ASPX n'est plus visible (les fichiers sont
quand meme présent mais ils sont vides).
Bref la version 2.0 apporte une bonne solution pour ce genre de
problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
-------------------
CS
"Messenger of the red snake mountain" wrote:
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même
> temps que Visual Studio 2005 et le .NET Framework 2.0.
>
> Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans
vsnet ?
Pour faire simple, le problème étant la protection des codes source lorsqu'on est éditeur de sites web (et oui c'est embétant que les clients puissent voir les sources).
Dans le Framework 1.1.
Dans une application ASP.NET 1.1, si tu as une page qui s'appele Default tu as : - d'un coté la partie HTML contenue dans le fichier Default.aspx - de l'autre la partie code (C#/VB.NET) contenue dans le fichier Default.aspx.cs.
Lorsque tu compiles ton projet sous Visual Studio, ton fichier Default.aspx.cs va être compilé dans une assembly (présente dans le rep /bin).
Lorsque tu déploies ton projet web, il te suffit de copier : - le fichier Default.aspx (et d'une manière générale tous les fichiers aspx, ascx et asmx) - le répertoire /bin qui contient le code compilé.
Donc tu n'as AUCUN fichier sources lors du déploiement ! Pour bien les choses, il te faudra en plus utiliser un outil "ofuscator" qui permet de masquer le code dans l'assembly (car il reste décompilable par reflexion .. cf un autre outil Reflector)
Le soucis c'est que les fichiers ASPX, ASXM et autres sont encore visibles et donc tu as peux protéger le code source mais pas les fichiers aspx.
Dans la version 2.0
Le mode de compilation a totalement changé, mais ce qui est intéressant c'est qu'il est possible de pré-compiler le site. La précompilation fait que TOUT le code C#/VB.NET/HTML/Javascript est intégré dans des assemblies.
Donc meme le code des fichiers ASPX n'est plus visible (les fichiers sont quand meme présent mais ils sont vides).
Bref la version 2.0 apporte une bonne solution pour ce genre de problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
------------------- CS
"Messenger of the red snake mountain" wrote:
> Cette fonctionnalité sera introduite dans ASP.NET 2.0 qui viendra en même > temps que Visual Studio 2005 et le .NET Framework 2.0. > > Cdt,
Bonjour,
Ne serait-il pas en train de parler du codebehind, présent actuellement dans vsnet ?
Antonio
Delf
Patrice wrote:
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Super pour la maintenance d'un site...
-- Delf
Patrice wrote:
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris
les pages ASPX, les images etc... !!!)
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Super pour la maintenance d'un site...
-- Delf
Messenger of the red snake mountain
> Bref la version 2.0 apporte une bonne solution pour ce genre de problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
Bien vrai.
Bon pour ma part, je travaille en 1.1 avec uniquement le code de présentation en aspx, et encore, ça c'est lorsque je dois permettre à un eventuel designer de toucher à la présentation. Dans certains cas où je souhaite cacher un maximum de code source (ou simplement avoir le modèle en DB) (selon choix politique) j'essaye plutôt de me retrouver avec une page vierge du genre:
Mon script de déploiement sur serveurs web supprime usuellement les fichiers portant les extensions suivantes: *.cs, *.aspx.*, *resx, *.csproj, *.csproj.*
Il ne reste plus grand chose après coup...
Antonio
> Bref la version 2.0 apporte une bonne solution pour ce genre de
problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
Bien vrai.
Bon pour ma part, je travaille en 1.1 avec uniquement le code de
présentation en aspx, et encore, ça c'est lorsque je dois permettre
à un eventuel designer de toucher à la présentation. Dans certains
cas où je souhaite cacher un maximum de code source (ou simplement
avoir le modèle en DB) (selon choix politique) j'essaye plutôt de
me retrouver avec une page vierge du genre:
Mon script de déploiement sur serveurs web supprime usuellement
les fichiers portant les extensions suivantes:
*.cs, *.aspx.*, *resx, *.csproj, *.csproj.*
> Bref la version 2.0 apporte une bonne solution pour ce genre de problèmatique. Mais meme avec la version 1.1, on limite pas mal des dégats.
Bien vrai.
Bon pour ma part, je travaille en 1.1 avec uniquement le code de présentation en aspx, et encore, ça c'est lorsque je dois permettre à un eventuel designer de toucher à la présentation. Dans certains cas où je souhaite cacher un maximum de code source (ou simplement avoir le modèle en DB) (selon choix politique) j'essaye plutôt de me retrouver avec une page vierge du genre:
Mon script de déploiement sur serveurs web supprime usuellement les fichiers portant les extensions suivantes: *.cs, *.aspx.*, *resx, *.csproj, *.csproj.*
Il ne reste plus grand chose après coup...
Antonio
Christophe Lauer [MS]
Delf wrote:
Patrice wrote:
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Super pour la maintenance d'un site...
Justement non !
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de logiciels qui veulent protéger la propriété intellectuelle des applications Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que ce soit, car l'éditeur de logiciels supporte son application mais usuellement pas des versions modifiées par les clients finaux.
Encore une fois, c'est une possibilité qui est proposée, pas imposée. Ensuite, comme toujours, c'est vous qui voyez... ;)
Cdt,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
Delf wrote:
Patrice wrote:
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y
compris les pages ASPX, les images etc... !!!)
Super pour la maintenance d'un site...
Justement non !
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de
logiciels qui veulent protéger la propriété intellectuelle des applications
Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas
que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que
ce soit, car l'éditeur de logiciels supporte son application mais
usuellement pas des versions modifiées par les clients finaux.
Encore une fois, c'est une possibilité qui est proposée, pas imposée.
Ensuite, comme toujours, c'est vous qui voyez... ;)
Cdt,
--
Christophe Lauer - Relations Techniques Editeurs de Logiciels
Division Développeurs et Plateforme d'Entreprise - Microsoft France
http://www.microsoft.com/france/msdn/
This posting is provided "AS IS" with no warranties, and confers no
rights.
A priori en ASP.NET 2.0, il sera possible de tout mettre en DLL (y compris les pages ASPX, les images etc... !!!)
Super pour la maintenance d'un site...
Justement non !
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de logiciels qui veulent protéger la propriété intellectuelle des applications Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que ce soit, car l'éditeur de logiciels supporte son application mais usuellement pas des versions modifiées par les clients finaux.
Encore une fois, c'est une possibilité qui est proposée, pas imposée. Ensuite, comme toujours, c'est vous qui voyez... ;)
Cdt,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
Delf
Christophe Lauer [MS] wrote:
Justement non !
Oui, c'est ce que je voulais dire :)
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de logiciels qui veulent protéger la propriété intellectuelle des applications Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que ce soit, car l'éditeur de logiciels supporte son application mais usuellement pas des versions modifiées par les clients finaux.
Dommage pour le client, s'il voulait retoucher lui-même le look des pages...
-- Delf
Christophe Lauer [MS] wrote:
Justement non !
Oui, c'est ce que je voulais dire :)
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de
logiciels qui veulent protéger la propriété intellectuelle des applications
Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas
que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que
ce soit, car l'éditeur de logiciels supporte son application mais
usuellement pas des versions modifiées par les clients finaux.
Dommage pour le client, s'il voulait retoucher lui-même le look des pages...
A priori, ce scénario s'adresse plus particulièrement à des éditeurs de logiciels qui veulent protéger la propriété intellectuelle des applications Web qu'ils livrent à leurs clients. Dans ce cas, il ne veulent surtout pas que les clients puissent "voir le code" ni qu'ils puissent modifier quoi que ce soit, car l'éditeur de logiciels supporte son application mais usuellement pas des versions modifiées par les clients finaux.
Dommage pour le client, s'il voulait retoucher lui-même le look des pages...
-- Delf
Messenger of the red snake mountain
> Dommage pour le client, s'il voulait retoucher lui-même le look des pages... Delf
Tout dépend des méthodes de développement qui seront utilisées par les éditeurs de solutions. Ceux appliquant la séparation entre la présentation et...le reste auront tout intérêt à laisser l'accès aux sources aspx.
En ce qui me concerne, c'est actuellement ma manière de travailler et j'en suis réellement satisfait. Je pars du principe que le client, s'il possède les ressources 'humaines' compétentes devrait être en mesure de personnaliser son interface. C'est, de plus, un bon compromis entre le main mise perdue sur le code source (la partie présentation est 'ouverte') et le travail supplémentaire qu'il aurait fallu fournir si le client avait souhaité disposer d'un assistant pour la gestion de l'apparence.
Ceux qui utiliseront cette technologie à fond, à savoir, en verouillant totalement le moindre fichier de l'application devront sûrement s'affranchir d'un travail supplémentaire et conséquent s'ils veulent permettre la modification visuelle de leur solution. Et s'ils ne le font pas, ce sera peut être un avantage concurrentiel pour d'autres!
Au final, je crois que cette fonctionnalité relève plus d'une option reflétant la politique de l'éditeur qu'autre chose...
Antonio
> Dommage pour le client, s'il voulait retoucher lui-même le look des pages...
Delf
Tout dépend des méthodes de développement qui seront utilisées par les
éditeurs de solutions. Ceux appliquant la séparation entre la présentation
et...le reste auront tout intérêt à laisser l'accès aux sources aspx.
En ce qui me concerne, c'est actuellement ma manière de travailler et
j'en suis réellement satisfait. Je pars du principe que le client, s'il possède
les ressources 'humaines' compétentes devrait être en mesure de personnaliser
son interface. C'est, de plus, un bon compromis entre le main mise perdue
sur le code source (la partie présentation est 'ouverte') et le travail supplémentaire
qu'il aurait fallu fournir si le client avait souhaité disposer d'un assistant pour
la gestion de l'apparence.
Ceux qui utiliseront cette technologie à fond, à savoir, en verouillant totalement
le moindre fichier de l'application devront sûrement s'affranchir d'un travail
supplémentaire et conséquent s'ils veulent permettre la modification visuelle
de leur solution. Et s'ils ne le font pas, ce sera peut être un avantage concurrentiel
pour d'autres!
Au final, je crois que cette fonctionnalité relève plus d'une option reflétant la
politique de l'éditeur qu'autre chose...
> Dommage pour le client, s'il voulait retoucher lui-même le look des pages... Delf
Tout dépend des méthodes de développement qui seront utilisées par les éditeurs de solutions. Ceux appliquant la séparation entre la présentation et...le reste auront tout intérêt à laisser l'accès aux sources aspx.
En ce qui me concerne, c'est actuellement ma manière de travailler et j'en suis réellement satisfait. Je pars du principe que le client, s'il possède les ressources 'humaines' compétentes devrait être en mesure de personnaliser son interface. C'est, de plus, un bon compromis entre le main mise perdue sur le code source (la partie présentation est 'ouverte') et le travail supplémentaire qu'il aurait fallu fournir si le client avait souhaité disposer d'un assistant pour la gestion de l'apparence.
Ceux qui utiliseront cette technologie à fond, à savoir, en verouillant totalement le moindre fichier de l'application devront sûrement s'affranchir d'un travail supplémentaire et conséquent s'ils veulent permettre la modification visuelle de leur solution. Et s'ils ne le font pas, ce sera peut être un avantage concurrentiel pour d'autres!
Au final, je crois que cette fonctionnalité relève plus d'une option reflétant la politique de l'éditeur qu'autre chose...
Antonio
Patrice
C'est une possiblité pas une obligation. Le modèle actuel reste valable et il sera également possible de tout compiler dynamiquement.
