Microsoft a annoncé hier soir la fin prochaine de Visual Studio pour Mac. Un mouvement à moitié surprenant seulement, car les signes s’amoncelaient depuis un moment. Pourtant, l’année dernière encore, l’environnement de développement avait reçu une mise à jour majeure.
Clap de fin pour Visual Studio pour Mac. La mouture actuelle 17.6 sera la dernière importante pour l’environnement. Elle sera maintenue pendant un an avec deux types de mises à jour : les correctifs de sécurité et les évolutions des technologies Apple.
« Nous continuerons également à fournir des mises à jour du runtime et de la charge de travail afin que vous puissiez continuer à créer et fournir des applications basées sur .NET 6, .NET 7 et les frameworks Mono. Bien qu'elle ne soit pas officiellement prise en charge, nous avons également activé une prise en charge rudimentaire de .NET 8 dans Visual Studio for Mac pour la création et le débogage d'applications. Nous espérons qu'avec ces engagements et l'investissement dans les alternatives ci-dessous, nous pourrons minimiser la perturbation de votre flux de travail sur Mac », indique Microsoft.
Mais au 31 août 2024, le support sera coupé. Visual Studio pour Mac pourra toujours être utilisé, mais aux risques et périls des utilisateurs, comme d’habitude dans ce genre de cas.
Selon Microsoft, cette décision a été prise après avoir noté les retours des développeurs et les statistiques d’usage. Manifestement, le jeu n’en valait plus la chandelle. Pourtant, l’année dernière encore, Visual Studio avait reçu sur Mac une nouvelle mouture majeure, qui en faisant notamment une application universelle, exploitant nativement les puces Apple Silicon, avec de très importants gains de performances à la clé.
La firme préfère cependant concentrer ses efforts sur d’autres produits, dont le Visual Studio classique pour Windows, qu’elle met d’ailleurs en avant dans l’annonce, puisque accessible via sa Dev Box « depuis n’importe quel système d’exploitation ».
Elle propose également plusieurs solutions de remplacement, selon les scénarios d’usage. Par exemple, Visual Studio Code avec le nouveau Dev Kit pour C# et les extensions associées, y compris pour MAUI (Multi-platform App UI) et Unity. Pour les personnes travaillant avec d’autres technologies comme Xamarin et F#, l’éditeur évoque un Visual Studio dans une machine virtuelle, une solution assez lourde. Autre piste, la même machine virtuelle, mais dans le cloud.
Des réactions vives
Le moins que l’on puisse dire, c’est que l’annonce n’a pas été bien reçue. La décision va nécessairement impacter des développeurs, mais elle pose surtout, aux yeux de certaines personnes, des questions sur l’avenir même de certaines technologies.
Dans les commentaires de l’annonce, on trouve de nombreux développeurs fustigeant les ruptures trop fréquentes dans les technologies du géant du logiciel. Si plusieurs pointent à Microsoft que Visual Studio Code n’est pas un vrai remplacement – n’étant pas un environnement de développement intégré complet – d’autres vont plus loin en assurant que certaines technologies, telles que MAUI, sont déjà condamnées.
« En tant que personne engagée dans la création d'une application MAUI complexe, cela me préoccupe. VSCode est sympa et tout, mais ce n'est pas un IDE complet, peu importe le nombre d'extensions que vous installez. L'extension MAUI est loin d'être un remplacement. Bien que je développe principalement sur Windows, cette décision me fait douter de la survie de MAUI », pointe par exemple Joshua Greenwald dans les commentaires.
Le responsable Anthony Cangialosi, à l’origine du billet, a d’ailleurs répondu : « Notre investissement dans MAUI reste inchangé. L'équipe .NET publiera de nombreuses mises à jour de MAUI .NET dans .NET 8. Nous comprenons que l'extension ne remplace pas un IDE complet, mais nous continuons à investir pour en faire une expérience exceptionnelle ».
Pour d’autres encore, la nouvelle n’est pas une surprise. Des rumeurs indiquaient en effet que le groupe de développement pour Visual Studio Mac avait été largement amputé pendant les dernières grandes vagues de licenciements.
Commentaires (31)
#1
Mmmh, VSCode reste?
#1.1
Oui :-)
Comme dit dans l’article, VSCode est même la solution qu’ils recommandent pour ceux qui utilisent les technologies liées à C# sous Mac.
#2
Boarf, pas besoin d’un ide, y a chatgpt qui fait maintenant tout le travail (sarcasme…)
#3
y’a pas d’équivalent sous mac sous licence libre et open source ?
#4
Libre ou open source, je ne sais pas moi j’utilise la suite JetBrains avec Rider et ça fonctionne superbement bien. L’IDE est multiplateforme (mac, windows, linux) très performant, intègre nativement resharper et je trouve l’UX et UI bien meilleure.
J’avais testé VS sous mac il y a quelques mois et l’essai avait été douloureux … Il est beaucoup moins puissant et complet que VS sous windows.
#5
Le truc qui devrait pourtant faire dissonance cognitive quand même!
#5.1
nous ne sommes plus en 1995…
#5.2
J’ai déjà vu du code server en C# et la liberté pour les employés de choisir leur OS.
Donc, non ça ne me choque pas.
A l’origine il me semble que c’était pour attirer les dévelopeurs mobiles à faire du WinPhone :p
#6
Ça dépend ce que tu veux faire. Pour du .net, je ne sais pas mais pour les autres langages, il y a les poids lourds (dans tous les sens du terme) : eclipse & netbeans
#7
Tout dépend de ce qu’on appelle “équivalent”.
Si c’est “juste” un éditeur + débuggeur, vscode fait le taf.
Si c’est du débogage avancé … là c’est chaud, sauf qu’il me semble que VS sous Mac n’est pas du niveau de VS sous Windows.
#8
quand je dit “équivalent” je veux dire un logiciel équivalent a Visual studio sous licence libre et open source !
#9
Depuis le temps qu’on fait du C# sous linux …
#10
Sauf que ce n’est pas assez précis… Eclipse est un équivalent à Visual Studio, par contre, il ne fait pas exactement la même chose…
En tout cas, il n’y a pas de “clone” opensource de Visual Studio.
Sur Mac, si c’est pour faire du dév Mac / iOS, il y a XCode qui n’est pas du tout opensource, par contre, Swift, le langage de programmation conseillé est lui opensource et multiplateforme.
#11
edlin puis make pour les vrais.
#12
Emacs ?
#13
Non c’est pas du tout « chaud », il y’a Rider qui est excellent. Y compris sous Windows d’ailleurs où c’est déjà un meilleur IDE que Visual Studio que ce soit pour le code, le debug et tous les à côtés.
#14
Avec AppCode, ça fait deux IDEs majeurs pour Mac qui disparaissent en moins d’un an…
#15
Je développe en C# quotidiennement et j’utilise Rider sous Windows (sur Mac plus ponctuellement ). C’est vraiment un chouette IDE, malheureusement il n’est pas gratuit comme pouvait l’être VS mac. En revanche par rapport à VS Windows, y’a pas photo, c’est clairement plus agréable. On a tous fait le switch dans ma boîte et personne ne s’en plaint (hormis les éternels « meh je trouve plus le bouton pour faire ça »). Par contre on n’utilise pas MAUI donc aucune idée du support dans Rider.
Je suis d’accord avec l’avis exprimé sur VS code, ça ne remplace pas un IDE complet même avec toutes les extensions du monde.
#16
Attention aussi de bien distinguer le dev perso et le dev pro. Perso au boulot je ne pourrais pas vraiment me passer de Visual Studio. J’ai testé VSCode mais franchement faut tout réapprendre et installer deux tonnes d’addons pour arriver à des trucs a peu près similaires.
Pas oublier non plus que Visual Studio à la base est conçu pour le C / C++, donc parler de dev C# ou web n’est pas spécialement relevant. C# avec notepad++ et les sdk tu peux le faire ;-)
#17
Sans compter la lourdeur du truc (en perfs et en ergonomie)
Je jetterai un oeil. J’utilise surtout les commandes directes et le débogage multithreads. Le débogage “GPU”, j’ai joué avec mais c’était pour faire mumuse. Par contre la connexion avec les insights des applis web, c’est cool.
#18
Tout comme on peut faire du C/C++ avec son éditeur préféré, la chaîne de (cross-)compilation et le système de build préféré (qui enveloppe presque toujours le très générique make sous une forme plus sexy/mieux cadrée). Et on peut tout faire avec juste les header de l’OS et librairies de base, sans même un SDK. Voir rien du tout en bare-metal (embarqué “machine à laver” ou pur démarrage, avant OS).
Je persiste à penser que vouloir aller dans du C#/.NET hors windows relève quand même d’un certain masochisme même si c’est pour moi l’occasion de voir que .NET semble arrivé sous Linux en 2017 (j’en été resté à Mono, qui rimait alors vraiment avec maso!): Je comprends que Microsoft trouve un intérêt à pousser son bidule, mais ne voit pas trop de raison de leur faire plaisir (surtout au vu du choix pré-existant).
#18.1
Je en connais rien en programation mais Emby est en .NET core 6.0 sur mon Synology et il tourne très bien.
#19
Coup dur, bon après ce n’est pas les alternatives qui manquent mais bon… JetBrains propose des solutions intéressantes, à consulter 😊
#20
L’écosystème .Net aujourd’hui n’a plus rien à voir avec l’écosystème .Net d’hier. Avec .Net core est apparu la portabilité grace à la scission d’avec Windows.
Faire du .Net Framework en dehors de Windows est effectivement pénible. Faire du .Net (anciennement .Net core) est tout à fait pertinent, quel que soit l’OS. Et j’en vois en faire sous Windows, Linux et Mac sans grande difficulté. Je constate juste que sous Linux et Mac, les développeurs ont tendance à utiliser plus facilement la ligne de commande que sous Windows !
#21
Que pensez-vous de vscodium ?
https://github.com/VSCodium/vscodium
https://vscodium.com/
Libre, facile à installer, fonctionnalité qui ressemble étrangement à vscode ;)
Je n’utilise plus que ca depuis quelques mois. RIP Atom et autres IDE
#21.1
VSCodium est à VSCode ce que Chromium est à Chrome.
VSCodium est édité par Microsoft et une communauté de volontaires. Microsoft ne fait qu’y ajouter ses outils proprio et sa télémétrie, et voici VSCode.
Bref, rien de bien différent sous le capot, juste quelques mouchards en moins.
édit : damn, j’avais pas vu la réponse de SebGF
#21.2
Attention, VSCodium n’a absolument et rigoureusement aucun lien avec Microsoft. C’est un projet communautaire qui se base sur les sources de VSCode disponibles sur GitHub en licence MIT.
Ca n’est pas la même chose que Chromium/Chrome.
Il faut plutôt voir ça comme les rebuilds de RHEL type AlmaLinux / Rocky Linux basés sur les sources de la distro commerciale.
#22
Normal, c’est un rebuild des sources de VSCode (qui sont sous licence MIT là où les binaires sont sous licence Microsoft non libre) avec la télémétrie et autres fonctions peu “privacy compliant” désactivées par défaut. Pas mal d’extensions sont absentes mais le magasin inclus reste bien fourni. On peut installer manuellement au besoin en utilisant l’archive.
A noter que toutes les extensions ne fonctionnent pas sur VSCodium car Microsoft rajoute une couche au build pour certaines.
C’est par exemple le cas de l’extension pour GitHub Copilot qui ne fonctionne pas dessus à cause d’un composant absent.
C’est perso ce que j’utilise à la place de VSCode.
#23
Y a t il bcp d utilisateurs de Mac chez les lecteurs de NextImpact?
Qui a vraiment travaillé avec VS pour Mac?
VS pour Mac n’avait pas grand
moi pas, et j ai jamais bien compris ce qu’était VS pour Mac
https://en.wikipedia.org/wiki/MonoDevelop#Visual_Studio_for_Mac
VS for Mac est d abord d un rename de MonoDevelop / Xamarin Studio qui existait déjà avant, à la suite du rachat de Xamarin par Microsoft en 2016.
Ensuite, j ai pas trop pigé si MS avait ré écrit une partie ou si il n y a jamais eu de lien et code partagé avec le ‘vrai’ Visual Studio sous Windows.
.NET MAUI est par ailleurs un autre projet issu du ‘merge’ des outils d interface de Xamarin et ceux de MS.
.NET MAUI est dispo dans l IDE d Apple Mac Catalyst, listé comme plateforme de dev pour Mac chez MS: https://learn.microsoft.com/en-us/dotnet/maui/supported-platforms pour le développement de .NET MAUI.
De ce pt de vue, le maintien de VS for Mac n est plus justifié,
Mais à lire certains commentaires sur le blog de MS, MacCatalyst est surtout un iOS intégré. prévu pour du dev pour iOS et iPadOS.
#24
VS pour Mac 2019 était un rename de Xamarin Studio / MonoDEvelop
VS pour Mac 2022 était apparemment un rewrite pour être natif sous macOS, donc le gros du boulot était fait. 1ere et dernière version native donc…
#25
Visual Studio pour Mac ne permettait pas de faire du C++, donc c’était assez différent de la version Windows dans tout les cas.