Code natif et managé dans Vista: l'envers du décor

Les possibilités

On commence maintenant à le savoir: Vista nous offre une foule de fonctionnalités bien pensées et très intéressantes: récupération automatique des applications, SideBar, envoi de rapports, transparence (thème "glass"), peer-to-peer, et j'en passe.

Bien sûr, les éditeurs de logiciel, donc les développeurs, voudront bénéficier de ces avancées en les intégrant à leurs applications (je veux que mon application soit en partie semi-transparente, qu'elle soit redémarrée en cas de problème, qu'elle fournisse des gadgets, et que j'obtienne des informations sur ses bugs après déploiement).

La déception

Seulement - et c'est là que le bas blesse - pour bénéficier de tout cela il faut appeler du code natif. Autrement dit, ces fonctions ne sont pas intégrées au framework .net (même pas dans le tout nouveau framework .net 3.0). Pour les utiliser depuis des applications .net (C#, VB.net et autres), il me faut donc faire des appels de plateforme. Vous savez, ces horribles DllImport. Déclarer moi-même les structures à utiliser et passer des HWND. Beurk!

Depuis maintenant 7 ans que le framework .net existe, on est en droit de s'attendre à s'intégrer avec Vista facilement avec une application .net. C'est à dire utiliser des classes du framework .net, et l'IntelliSense qui va avec dans Visual Studio 2005.

Pourquoi donc ce retour en arrière? Apparemment, un wrapper des ces APIs dans le framework .net était prévu, mais les équipes de développement de Microsoft ont manqué de temps d'après Jason McConnel, Product Manager de Visual Studio.

Comment faire?

Cet article de décembre 2006 semble indiquer que Microsoft veut encourager les développeurs à mélanger du code natif et du code managé. C'est même confirmé par ce document de Microsoft, qui explique que pour s'intégrer à Vista avec du code managé, il va falloir se retrousser les manches et faire du PInvoke.

Il est vrai que C++/CLI le permet, mais pour avoir donné dedans je peux vous dire que ce n'est pas non plus évident. Cette solution serait plutôt un aveu de faiblesse de Microsoft.

Bien sûr, le plus logique serait que Microsoft fournisse une prise en charge dans le framework .net, c'est à dire qu'ils écrivent eux-mêmes l'assemblage d'intéropérabilité. Ils l'ont bien fait pour Office et DirectX par le passé. Mais pour ça il faut en faire l'effort, et il semble que ce ne soit pas prévu.

Quel futur?

Au doigt mouillé, je pense que Microsoft va in fine (dans le framework 3.5?) écrire l'API managée d'intéropérabilité. Ou alors ce sera une autre société qui s'en chargera. Dans un monde qui devient de plus en plus .net, cela paraît plus que trivial.

Ou alors - hypothèse plus négative - Microsoft n'investit pas dans le framework .net car il compte l'abandonner. Ca me semble assez absurde, mais ceci pourrait expliquer cela.