Microsoft renverse la demande de portage de Visual Studio Tools pour Office vers .NET Core de « Bien sûr, nous allons jeter un œil » à « Non »

  • FrançaisFrançais



  • Microsoft a fermé une demande de longue date pour porter Visual Studio Tools pour Office (VSTO) vers .NET Core, déclarant qu’il “ne mettra pas à jour VSTO ou la plate-forme de complément COM pour utiliser .NET Core”.

    Le problème a été soulevé en octobre 2019 par un développeur avec des compléments Excel VSTO écrits en C#. “Winforms a été porté sur .NET.Core. Veuillez également porter VSTO en C# vers .NET 5, pour permettre le développement de modules complémentaires en C# dans le ‘nouveau .Net'”, ont-ils demandé.

    Microsoft était initialement réactif et le problème a été « mis en file d’attente pour priorisation » le mois suivant. Cependant, la semaine dernière, il a été fermé sans correction “parce que .NET Core/.NET 5+ ne peut pas fonctionner avec .NET Framework dans le même processus et peut entraîner des échecs de chargement du complément”.

    Le message, attribué à “Feedback bot”, a assuré aux développeurs que “la plate-forme de compléments VSTO/COM est très importante pour Microsoft” et a promis de continuer à la prendre en charge avec la version héritée de .NET, mais a également déclaré que “la recommandation aller de l’avant est d’utiliser les API JavaScript multiplateformes.”

    Les applications Office telles que Word et Excel sont parmi les plus anciennes de Microsoft et il existe un certain nombre de façons de les étendre et de les automatiser, certaines étant désormais considérées comme héritées mais toujours prises en charge en raison de leur large utilisation dans les entreprises. L’ancien style Visual Basic (avant VB.NET) se perpétue sous le nom de VBA, le langage macro Office.

    VSTO a été introduit en 2003 comme un moyen d’utiliser .NET pour coder des solutions basées sur Office. Il est basé sur COM, le modèle objet de composant Windows, et a accès à toutes les API exposées par Office. Cependant, VSTO est uniquement Windows. Vers 2012, Microsoft s’est lancé dans une nouvelle façon d’étendre Office à l’aide d’une API JavaScript, appelée Office Web Add-ins ou parfois simplement Office Add-ins. Ceux-ci sont hébergés sur des serveurs Web et utilisent les API JavaScript Office plus limitées.

    L’avantage est qu’ils fonctionnent en multiplateforme, sur mobile et sur le web. Les deux approches ont peu en commun et il n’y a aucun moyen de migrer le code côté client autrement qu’en le convertissant en JavaScript.

    L’avènement de .NET Core 3.0 à la fin de 2019 a vu Microsoft prendre en charge des technologies uniquement Windows telles que Windows Forms et Windows Presentation Foundation avec sa version multiplateforme de .NET, ce qui a amené les développeurs de VSTO à espérer que .NET dans Office serait également mis à jour. car beaucoup n’avaient pas fait la transition vers l’API JavaScript.

    “Nous en avons grandement besoin… Les compléments JS ne fonctionnent pas pour nos cas d’utilisation, et nous avons déjà une grande base de code existante dans les bibliothèques .NET Standard”, a déclaré un autre développeur.

    “Notre cadre de prévision repose sur un complément Excel interagissant avec un tableau croisé dynamique OLAP, qui n’est pas pris en charge dans OfficeJS”, a déclaré un autre codeur.

    La déclaration de Microsoft a mal tourné. En réponse à la question « pourquoi ne pas utiliser JavaScript ? ils insistent sur le fait qu’il ne dispose pas des fonctionnalités dont ils ont besoin, que les performances sont inférieures aux normes et que le besoin d’une application Web est un fardeau.

    En réponse à la question « pourquoi ne pas être satisfait de .NET Framework 4.8 (la dernière version) ? ils disent que les performances ont pris du retard, qu’ils veulent de nouvelles fonctionnalités comme la prise en charge native des plates-formes ARM, et que la compatibilité avec d’autres bibliothèques .NET sera un problème à l’avenir.

    “Je pourrais vivre avec la version 4.8, sauf qu’il y a tellement d’améliorations pour .Net Core 5/6”, a déclaré un autre développeur. “Nous soutenons et ajoutons des fonctionnalités à une grande application Word VSTO pour le gouvernement… Peut-être que Microsoft pourrait ouvrir le code VSTO afin que les utilisateurs puissent le déplacer vers une version .Net Core moderne.”

    Legacy ahoy : types de compléments dans Word

    Legacy ahoy … Types de compléments dans Word

    Le problème technique est délicat. Le problème est que tandis qu’un certain groupe de développeurs poussent à mettre à niveau vers .NET 5.0 ou le prochain .NET 6.0, il y aura toujours d’autres compléments qui utilisent .NET Framework, et actuellement les hôtes COM (comme Office) ne peuvent prendre en charge que une version d’un runtime .NET. Par conséquent, un complément qui nécessite .NET Framework casse celui qui nécessite .NET Core, et vice versa. Il peut également être nécessaire de prendre en charge plusieurs versions de .NET Core, car les applications peuvent spécifier celle qu’elles prennent en charge. Les raisons de la limitation ne sont pas fondamentales mais il s’agit d’un scénario que Microsoft n’a ni prévu ni testé.

    Une discussion ici sur l’exécution côte à côte des versions .NET Framework et .NET Core couvre certains des problèmes. « Plusieurs versions de .NET Core exécutées simultanément vont devenir très risquées », a déclaré l’ingénieur logiciel principal Aaron Robinson.

    L’histoire suggère que Microsoft continuera en effet à prendre en charge VSTO basé sur .NET Framework dans un avenir prévisible. Les perspectives d’un changement d’avis concernant VSTO sur .NET Core semblent toutefois minces, malgré les réelles limitations rencontrées par les développeurs lorsqu’ils essaient d’utiliser les API JavaScript. Office fonctionne toujours mieux sur Windows, mais c’est la preuve que l’entreprise est prête à le laisser prendre du retard en tant qu’application Windows native, dans le but de pousser les développeurs vers des solutions Web multiplateformes. ®

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *