Version imprimable
Bonjour,
je dois ajouter de nouveaux modules,pages, formulaires.... sur un site fait integralement en asp 3.0.
Est il possible de faire cohabiter des pages asp.net avec les pages asp ?
Quelles sont les containtes ? sessions, cookies ..... ?
Merci à vous
heu asp 3.0, c'est de l'asp .net non?
en tous cas asp 2.0 est de l'asp .net
nonCitation:
Envoyé par bobby51
non plus :)Citation:
en tous cas asp 2.0 est de l'asp .net
tu as différentes choses
ASP (Active Server Page) dont la dernière version est la 3.0. c'est vieux ca date d'avant l'an 2000. on dit donc "asp 3.0" ou encore "ASP Classic"
puis tu as l'ASP.Net qui existe depuis 2001
ASP.Net 1.0
ASP.Net 1.1
ASP.Net 2.0 (et pas "asp 2.0")
ASP.Net 3.5
il n'y a donc strictement rien à voir entre ASP et ASP.Net. et sa question est donc pas si simple
@topolino
ASP et ASP.Net sur le même serveur => OUI
ASP et ASP.Net sur le même projet Web => pas convaincu voire pas du tout. car stocker des objets en .Net en Session voudrait dire que tu pourrais récupérer ces objets en ASP, et je vois mal ASP gérer un générique :)
niveau binaires, ca marcherait (pas meme extension handler) mais après c'est au niveau fonctionnement (transfer, etc)
niveau cookie, là c'est différent à condition d'être sûr de ne jamais passer en cookieless parce que là, ASP, je suis pas convaincu qu'il aime également :)
t'as plutôt intéret à faire deux projets séparés voire recoder parce que l'ASP pour en avoir écrit pas mal, c'est vraiment mal foutu (gestion des exceptions, etc). mais si les échanges sont limités, beaucoup de gens ont réussi à le faire sur le net (passage de variables via GET par exemple)
Merci d'avoir précisé les differences pour ceux qui ne les connaissaient pas.
Mais cela ne regle pas mon problème ;o).
bah je te répond en dessous, tu lis pas jusqu'au bout? :)Citation:
Envoyé par topolino
+1 LGM
- réecriture si il y a un gros besoin d'evolution
- maintenance en ASP 3.0 si les modifications sont non critiques et peu nombreuses par rapport a l'existant.
La maintenabilité d'une application à cheval sur les 2 languages (qui ont quand meme beaucoup de differences) est difficile...
Ou alors, il faut vraiment que les nouvelles fonctionnalités n'aient rien à voir avec les anciennes.... en general cette analyse s'arrete a la securité/identification du user qui pose probleme sur les nouvelles pages... et c'est une vision a court terme.
Pour precision, il me semble qu'il n'y a pas de partage de session entre ASP et ASP.Net (de memoire)
PS: confirmé par la FAQ pour les variables de session
Il est possible de publier deux projets de deux langages différents sur un même seveur virtuelle. Je l'ai déjà fait avec un site asp.net 2.0 et asp.net 3.5. Mais la maintenabilité est difficile, et tu as plusieurs contraintes : un et un seul fichier global.asax, un seul web.config...
En revanche j'ai réussi à transmettre des infos d'une appli à l'autre à travers la session. Il s'agit de type simple (string, int...). Pour les objets spécifiques, cela ne fonctionne que si les deux applications connaissent le type.
Je ne pourrais pas te dire si le passage entre asp et asp.net est possible.
Merci pour vos reponse.
Ce que j'ai pu lire sur le net, c'est que pour la transmission des objets session, peut se faire via la generation d'un formulaire à la volée que je redirige via un (action=post) vers l'autre language (asp ou asp.net).
Qu'ne pensez-vous ?
bah oui, post ou GET mais ca revient au même. ca depend ce que tu veux trimballer dans ta session. ici, ca te permet d'envoyer des strings et rien d'autre
niveau mise en place, c'est ultra bancal, ca t'oblige à remodifier toutes les pages (envoyant les infos, et celle recevant), simplement pour bidouiller ce mecanisme :?
est-ce que c'est pas plus rapide que migrer le code? y a des outils qui sont faits pour ca en plus et qui rendent cela très rapide à faire
voir rester sur ASP 3.0....( ben oui, ca pourrait se justifer)Citation:
Envoyé par Louis-Guillaume Morand
ou reecrire tout en ASP.Net (et pourtant je suis generalement contre repartir from scratch).
Ca depends vraiment de l'existant, du volume des modifications à faire, la valeure ajoutée de l'application.
Mais ASP.NET et ASP ne partagent pas grand chose en fait.... rester sur un modele hybride ca ne peut etre que temporaire pour moi....
Le faite de migrer necessite une phase assez longue concernant la conception et de penser a une architecture qui tienne la route.
Le probleme est que l'ont manque de tps et de budget pour tout migrer d'un coup. Il faut donc le faire petit a petit, d'autant plus que l'equipa actuelle non aucune idee de comment marche .net voir de la poo !!!!!
c'est toi qui connait le nombre d'interactions asp<->asp.net qu'il y aura.
si le gros de l'existant est en ASP et avec trois pages asp.net, ca va aller si apres, y a plus d'une dizaine de pages asp.net avec des echanges eventuellement complexes, ca risque d'etre plus dur.
il faut faire un POC et vous pourrez voir si c'est possible et/ou avoir une estimation du coût de développement de ce "mix"
C'est tout le probleme en general, mais il faut des objectifs clair dès le depart.Citation:
Envoyé par topolino
dans ce genre de situation je fais dans le binaire ^^
S'il n'y a pas de temps et de moyen, c'est que l'application n'est pas critique. :mrgreen: Alors pourquoi se poser des questions, on reste en ASP 3.0 tant que c'est supporté, et voila.
L'application est critique, on veut la faire migrer:
un plan d'action classique est
- Gel de l'application en production (pas de modification autre que break/fix)
- Portage de l'application en l'etat (et la migration ou reecriture depends beaucoup de la capacité a faire des tests fonctionnels qui couvrent bien l'existant pour ne pas repasser par une grosse phase de regression... c'est souvant un soucis ca aussi)
- refactoring (eventuel)
- Ajout/modification de fonctionnalitées
Les autres approches peuvent sembler plus rapide mais a moyen terme ammenent à faire le grand ecart pour gerer un bidule etc etc.. et grandement degrader la maintenabilité et au final couter plus cher qu'un portage complet, a mon sens.
La encore, il peut y avoir des souplesses suivant la taille de l'existant etc, mais il faut avant tout un plan et eclater la migration totale en "migration par tranches" etc..
PS:
tout a fait d'accord avec LGM pour le Proof Of Concept
Je me demandais, ca ne serait pas malin de faire une archi SOA en .net et de consommer les webservices en asp 3.0. Toutes la parties metiers, dal.... seront deja faite. Et une fois que la gestion "session" reglée entre autre comme pb entre asp.net et asp 3.0, on passe petit a petit les page asp en aspx.
a votre avis ?
Mutualiser ce que tu vas faire en .Net (et pourquoi pas sous forme de webservice) ca peut etre interessant (faut voir le contexte aussi).
le plan que tu proposes est tout a fait possible.
il a l'avantage d'etre un peu asynchrone et incrementale:
je cree le service - je le test - je modifie partiellement une page pour consommer ce service uniquement -
Un avantage aussi, le decoupage en service aide a identifer les tests fonctionnels necessaires.
Maintenant il y a plusieurs criteres a voir:
- Est ce que l'equipe maitrise la consommation de services web en ASP 3.0 (c'est plus "traps" qu'en .Net de memoire)
- Est ce que le code original est "designé" de maniere a pouvoir passer a une consommation de service, ou est ce que la logique metier et les problematiques d'interfaces sont un peu trop imbriquées pour faire une séperation aisée...
Autrement dit:
page full ASP -> Page ASP + WS .Net -> Page ASPX + WS.NET
sera-t-il plus rapide/simple/sure que
Page full ASP -> Page ASPX migré/reecrite (-> Page ASPX refactorisé (+WS.NET))
ca ca depends beaucoup du code existant et des equipes...
Vraiment merci Rami pour tes reponses.
En faite, l'application asp deja developpée existe depuis 10 ans. Donc il n'y a pas de reelle architecture et de conception.
La societe sait pertinement que la migration est inevitable, et qu'il faut continuer à developper de nouvelles fonctionnalités.
C'est pour cela que je me dit que les nouvelles fonctionnalités peuvent etre passées en WS pour commencer une migration et poser deja les bases sur une architecture SOA afin de gagner du temps et que la migration se fasse petit a petit. Car le refonte de certaine partie se basera elle meme sur cette nouvelle architecture.
Le faite de consommer des WS a partir de asp3.0 est plus critiques ? les perfs desendent vraiment ?
le donc n'est pas evident. il y a 10 les dev. faisaient deja des developpement modulaires tres bien concus ^^Citation:
Envoyé par topolino
cette petite remarque de faite, il est vrai qu'une application qui n'as pas subit de refactoring régulier a tendance à perdre ses ressources critiques, voir sa documentation technique et fonctionnelle non maintenues etc... surtout sur de longues periodes.
D'ou la difficulté. (preparez vous à une phase de regresssion :? )
Pour ce qui est des web services et de L'ASP 3.0 c'est surtout que c'est un peu plus de "tuyauterie" à coder et que c'est moins bien documenter sur le net. Il faut plutot des "barbus" de l'ASP pour s'attaquer à ca... alors que consommer un WS en ASP.Net, trois coup de google et c'est bon (je caricature enormement... c'est juste pour essailler d'etre clair). Pour ce qui est des perf, j'avoue ne pas avoir d'info.
Dans tous les cas, maintenant que tu as l'air d'etre plus clair sur ce qui t'attends, l'etape 1 (pour moi) est de faire le decoupage fonctionnel de l'application (meme grossier). Que ce soit pour identifier les services a implementer, les points de communications, les priorités dans la migration, les tests a identifiers, etc...
bon courage.