Migration XMLRAD8 -> 2005

**rgarnier** · 22/12/2005, 10h06

Bonjour,

Mes chers tortionnaires de patrons m'ont demandé de me pencher sérieusement sur la potentielle migration de notre appli XMLRAD en .NET.

Toujours confiant en XMLRAD, je leur ai répondu que cela ne devrait pas poser de pbs insurmontables.

Voici ce que j'imaginais faire:
- Migrer de XMLRAD8 à XMLRAD2005 (R2 qui a l'air bien stable)
- Migrer de Delphi 7 à Delphi 2005 (ou 2006 selon l'époque)
- Gérer le même projet et compiler soit en Win32, soit en .Net. Ce dernier point est-il vraiment réalisable ou bien est-ce un rêve de développeur ????
Cela me permettrait de continuer à faire évoluer l'appli et de passer en douceur sur .NET.

Merci de vos conseils

**RDM** · 22/12/2005, 13h39

Envoyé par rgarnier

Voici ce que j'imaginais faire:
- Migrer de XMLRAD8 à XMLRAD2005 (R2 qui a l'air bien stable)

il est clair que c'est le bon choix de version surtout qu'elle intègre le module de migration.
bon par contre pas pour le code

- Migrer de Delphi 7 à Delphi 2005 (ou 2006 selon l'époque)

2006, définitivement 2006 !!

- Gérer le même projet et compiler soit en Win32, soit en .Net. Ce dernier point est-il vraiment réalisable ou bien est-ce un rêve de développeur ????
Cela me permettrait de continuer à faire évoluer l'appli et de passer en douceur sur .NET.

c'est totalement réalisable ! le framework lui même compile pour les 2 plateformes sans problèmes.
il faut cependant t'assurer que tu n'utilises que ldes objets du Framework et si tu utilises autre chose que ca ne soit pas trop lié à la plateforme Win32 sinon => $IFDEF

au passage, ne t'attend quand meme pas au même performance qu'en Win32. Actuellement avec le framwork 1.1, le processeur XSL est à la traine par rapport a MSXML 4.0.

**Sylvain James** · 22/12/2005, 14h47

[quote="RDM"]

Envoyé par rgarnier

au passage, ne t'attend quand meme pas au même performance qu'en Win32. Actuellement avec le framwork 1.1, le processeur XSL est à la traine par rapport a MSXML 4.0.

A ce propos, je croyais que la transfo xsl ne passait pas par le framework .NET mais via COM (MSXML) via un PInvoke, ce qui réduisait considérablement le temps d'exécution ?

Concernant la migration Win32 -> .NET, j'étais présent au séminaire Delphi 2006 et j'ai filmé les sessions. Les films devraient être bientôt accessibles sur Developpez.
Une des sessions traitaient de la migration, il serait intéressant pour toi que tu (Renaud) la visionnes (contacte moi en MP je te filerai une url pour la downloader avant la parution si c'est urgent).

Au passage, on parlait récemment du futur repas XMLRAD. Comme c'est pas évident pour toi de venir à Paris, essaie de voir si tu peux trouver un créneau, à partir de là on lancera "l'appel à candidatures" :-)

à+
Sylvain

**RDM** · 22/12/2005, 20h34

Envoyé par Sylvain James

A ce propos, je croyais que la transfo xsl ne passait pas par le framework .NET mais via COM (MSXML) via un PInvoke, ce qui réduisait considérablement le temps d'exécution ?

c'etait une alternative, qu'ils ont essayés, mais qui n'est pas compilée dans la version distribuée. elle doit être juste en commentaire dans XMLCLX.XMLCursor.
parce que l'idée c'est d'être pur .NET. bon ca changera peut être à l'avenir mais c'est une autre histoire...

**Sylvain James** · 22/12/2005, 22h31

ok, de toute façon il semblerait que les perfs XSL soient nettement améliorées (x 4) dans la nouvelle version du framework .NET (2.0)

**rgarnier** · 23/12/2005, 14h29

Ok, merci pour les infos.

Pour RDM

2006, définitivement 2006 !! Rolling Eyes

J'avoue avoir passé les 6 derniers mois sans trop xmlrader (commerce oblige), pquoi pas Delphi 2005 ?? 2006 étant tout frais....

**RDM** · 23/12/2005, 14h43

2006 est tout frais mais ca fait depuis avril qu'elle est en beta test quand meme et personnelement on avu tout le travail qui a été fait pour stabilisé et optimisé l'IDE.
2005 est largement reconnu pour être la plus instable des versions de Delphi (pire que la 4)
pour te dire on est passé de Delphi 7 pour notre IDE de dev à 2006. sans passer par la case 2005.

autre question: dans quel but veux-tu passer en .NET ? c'est vis à vis des clients ?

**rgarnier** · 23/12/2005, 16h51

en fait, il y a 3 raisons :

1 - L'avenir ne se fera certainement pas sans .NET, et donc, vu que le travail pour être compatible semble à portée de main, au plus tôt on y est au mieux on se portera.

2 - Dans la continuité de la 1°, l'enjeu commercial n'est pas négligeable.

3 - On travaille avec ORACLE pour 90% de nos clients, et comme le driver OLEDB de microsoft se base sur un OCI version 7 et n'évoluera plus, cela nous pose de gros pb de stockage de donnée dû aux restrictions BD. Et évidemment, on ne peut pas se vendre comme au fait de la technologie en proposant une structure ancienne.

Voilà pour le contexte.

P.S. : bon Noël à tous.

**RDM** · 23/12/2005, 17h16

Envoyé par rgarnier

en fait, il y a 3 raisons :

1 - L'avenir ne se fera certainement pas sans .NET, et donc, vu que le travail pour être compatible semble à portée de main, au plus tôt on y est au mieux on se portera.

Alors il faut faire la différence sur 2 trucs:
1/ il est clair que microsoft va mettre du .NET de partout
2/ l'OS n'est toujours pas lui en .NET mais toujours en natif, pour au moisn les 10 ans qui viennent et les API Win32 ne vont pas disparaitrent (au contraire il y en aura plus dans Windows Vista)
donc au final le natif a encore de très beau jour devant lui et Delos va continuer largement sur cette voie qui donne les meilleurs performances et une mailleure maitrise des composants systèmes (Allocation mémoire, switch de context, etc.)

pour tout te dire, ils envisagent de passer le framework qui est actuellement en pur .NET sur le même principe que Java, a savoir un noyau natif et une exposition des objets en .NET.
autre chose aussi qu'ils envisagent c'est un retour au string (et non pas WideString) avec abandon des objets COM et TLB.
Tout ca dans un soucis permanent de performance.

2 - Dans la continuité de la 1°, l'enjeu commercial n'est pas négligeable.

.NET reste pour moi un problème de développeur.

3 - On travaille avec ORACLE pour 90% de nos clients, et comme le driver OLEDB de microsoft se base sur un OCI version 7 et n'évoluera plus, cela nous pose de gros pb de stockage de donnée dû aux restrictions BD. Et évidemment, on ne peut pas se vendre comme au fait de la technologie en proposant une structure ancienne.

j'en déduis qu'en passant a .NET avec le Data Provider fourni par microsoft pour Oracle tu penses que lui sera maintenu plus à jour. par contre question performance gloable j'ai des doutes.
pour un driver OleDb a jour tu peux toujours prendre celui d'Oracle. je sais bien qu'il est moins performant et que c'est cette raison qui vous avez passez sur MSDAORA.
mais globalement, je suis pas sur qu'en passant tout en .NET tu y gagnes.
maintenant Delos pourrait envisager de faire un DacOracle natif...

**rgarnier** · 24/12/2005, 13h26

j'en déduis qu'en passant a .NET avec le Data Provider fourni par microsoft pour Oracle tu penses que lui sera maintenu plus à jour

en effet, c'est le cas, le driver win 32 est en status maintenance et n'évolue plus depuis quelques années. Par contre microsoft suit les évolutions d'oracle dans .Net.
Le driver Oracle étant tellement nul, il n'y a pas trop dautre alternative.

.NET reste pour moi un problème de développeur.

je ne suis pas trop d'accord sur ce point, c'est une stratégie technique et commerciale, mais bon, ça se discute.

maintenant Delos pourrait envisager de faire un DacOracle natif...

Alors là, ce serait vraiment bien. Une super évolution. Je vote pour et veut bien essuyer les platres.[/quote]