OmniSharp rend la programmation .NET multiplateforme

Version imprimable

06/01/2015, 14h33
Hinault Romaric

OmniSharp rend la programmation .NET multiplateforme

OmniSharp rend la programmation .NET multiplateforme
l’outil permet d’utiliser .NET dans votre éditeur préféré sur Windows, Linux et Mac

Microsoft a fait un grand pas il y a quelques mois vers la communauté open source en annonçant .NET Core, son fork open source de la plateforme .NET.

.NET Core est une implémentation modulaire, qui pourra être utilisé dans une grande variété de plateformes. L’ambition de Microsoft est de rendre .NET accessible à un nombre plus important de développeurs, sous plusieurs plateformes, y compris Linux et Mac.

Avec .NET Core, les développeurs peuvent dorénavant créer des applications ASP.NET 5 (prochaine version majeure de plateforme de développement Web ASP.NET) qui fonctionnent sur Windows, Mac et Linux.

Cependant, le développement .NET est extrêmement lié à l’environnement de développement Visual Studio, qui ne fonctionne que sur les systèmes d’exploitation Windows. Certes, il existe MonoDevelop, qui est un EDI cross platform permettant de créer des applications Web et Desktop en .NET sur Linux, Windows et Mac OS X. Mais, si le développeur pouvait exploiter l’EDI de son choix pour faire du développement .NET ?

C’est le défi que promet de résoudre OmniSharp, un ensemble de projets open source, chacun ayant pour objectif de rendre possible le développement .NET dans votre EDI. Le projet est actuellement maintenu par 8 développeurs, dont deux personnes de chez Microsoft. On y retrouve notamment Scott Hanselman, de Microsoft. Il faut noter cependant qu’il ne s’agit pas d’un projet de Microsoft.

« C’est amusant de dire que .NET est Cross platform. Mais, est-il raisonnable pour quelqu’un de développer en .NET sans Visual Studio et Windows ? », peut-on lire sur la page du projet. « Est-il amusant de faire du .NET sur un Mac avec Sublime ? Sur Ubuntu avec Emacs ? Sur Windows avec Atom ? »

Avec OmniSharp, vous serez désormais en mesure d’utiliser votre EDI pour créer des applications en .NET et déployer celles-ci partout, tout en bénéficiant des fonctionnalités intéressantes de Visual Studio comme l’IntelliSense, l’ajout des références, des formats de documents, la refactorisation, etc.

http://www.developpez.com/public/ima...ws/IkirwAE.gif
IntelliSence avec Sublime Text

Pour cela, il vous suffit de télécharger la version d’ASP.NET 5.0 pour votre plateforme, et installer les outils nécessaires en fonction de votre environnement de développement.

Actuellement, Sublime Text 3, Vim, Atom de Github, Emacs et Adobe sont pris en charge par OmniSharp. Le projet fonctionne comme un processus indépendant et exécute une API Web qui communique avec votre éditeur. Il suffit donc, de développer des plug-ins pour l’étendre à d’autres EDI, notamment Eclipse.

Le développement de OmniSharp est encore en cours, et ses développeurs espèrent à terme pouvoir l’intégrer avec le compilateur Roslyn. Pour l’instant, uniquement le support d’ASP.NET 5 est offert.

Pour rappel, ASP.NET 5 est un projet open source conçu à la fois pour le Cloud et les serveurs. La plateforme introduit un nouveau mode « cloud optimized », qui est plus rapide et utilise moins de ressources que la version actuelle de .NET. Ce mode permet de déployer des applications .NET avec des copies des bibliothèques du Framework .NET.

:fleche: Télécharger OmniSharp et ses outils de développement

Source : Le site du projet

Et vous ?

:fleche: Que pensez-vous de OmniSharp ? Allez-vous tester le projet ?
06/01/2015, 14h49
dfiad77pro

C'est très intéressant comme type de projet et d'ouverture.

Cela dit outre les fonctionnalités textuelles et référentiel d'un IDE,
Visual studio possède énormément d'outils pas forcément simples à implémenter (coded UI, Designer , profiler ...),

Ce qui fait la force de Visual studio en .NET c'est qu'on peut faire énormément de choses de manière unifié.
je ne suis pas sur qu'assez de volontaires se lanceront dans ce genre de projet afin d'égaler Visual studio sur ces points dans une solution unifiée (même en java on à pas 20000 IDE complets).

Je pense qu'on va plutôt à terme se retrouver avec un IDE éprouvé genre Eclipse For Dotnet (ce qui signifiera une implémentation l’analyse syntaxique et grammaticale, du compilateur roselyn , donc une foultitude de pluggins).

Bref dans quelque mois on aura le sujet suivant sur dev.net : les DSI vont-il imposer Eclipse à la communauté .NET ? :mouarf:
06/01/2015, 15h04
redcurve

Citation:

Envoyé par dfiad77pro

C'est très intéressant comme type de projet et d'ouverture.

Cela dit outre les fonctionnalités textuelles et référentiel d'un IDE,
Visual studio possède énormément d'outils pas forcément simples à implémenter (coded UI, Designer , profiler ...),

Ce qui fait la force de Visual studio en .NET c'est qu'on peut faire énormément de choses de manière unifié.
je ne suis pas sur qu'assez de volontaires se lanceront dans ce genre de projet afin d'égaler Visual studio sur ces points dans une solution unifiée (même en java on à pas 20000 IDE complets).

Je pense qu'on va plutôt à terme se retrouver avec un IDE éprouvé genre Eclipse For Dotnet (ce qui signifiera une implémentation l’analyse syntaxique et grammaticale, du compilateur roselyn , donc une foultitude de pluggins).

Bref dans quelque mois on aura le sujet suivant sur dev.net : les DSI vont-il imposer Eclipse à la communauté .NET ? :mouarf:

Surtout pas Eclipe ce soft est une horreur
06/01/2015, 15h38
Seb33300

Je peux comprendre l'idée de proposer des alternatives.
Mais quitte à développer une appli .NET, autant utiliser visual studio. Je ne pense pas qu'il puisse une jour exister un équivalant qui puisse rivaliser à tous les niveaux.
De toute façon, je doute que les "pro-linux/mac" se tournent un jour vers du développement .NET.
06/01/2015, 15h47
dfiad77pro

Citation:

Envoyé par Seb33300

De toute façon, je doute que les "pro-linux/mac" se tournent un jour vers du développement .NET.

Oh j'en connait un ( chercheur et poète moustachu complétement félé du language) qui est fan de C# et F#(mais en temps que langage pure) :D
06/01/2015, 15h55
anthyme

gnome a bien une dépendance sur mono donc des linuxiens qui font du C# il y en a depuis déjà pas mal de temps ;-)
06/01/2015, 16h42
codec_abc

Cette initiative me plait bien. Je vais surement tester l'intégration sous Atom dans les prochains jours.
06/01/2015, 17h09
Washmid

Pour linux + c#, l'énorme avantage de .NET sur Java est qu'il permet d'obtenir des applications très dépendantes de la plateforme, contrairement à java où faire du Gnome, par exemple... bonne chance.

Ce n'est pas la portabilité de .NET qui plait sur Linux, c'est le fait que les applis qu'on crée avec soient extrêmement intégrées à Gnome & co (la plupart du temps).

Bref, c'est pour répondre à Seb33300 et d'autres :)
06/01/2015, 20h37
imikado

Citation:

Certes, il existe MonoDevelop, qui est un EDI cross platform permettant de créer des applications Web et Desktop en .NET sur Linux, Windows et Mac OS X.

Il ne me semble pas :(
Je developpe en ce moment avec monoDevelopp et on génère des applications mono et Mono (implémentation libre de .net) et non .Net
Il y a une grosse différence

Par exemple pour la partie graphique je fait du GTK# et non du winforms ou WPF...

Et un autre exemple: je compile sur mon Linux, et l'application ne fonctionne pas sur mon windows où mono n'est pas installé :(

Autre chose, il me semblait avoir lu que c'était ASP.net qui allait être multi plateforme et non .net tout entier... à confirmer
06/01/2015, 23h02
Lutarez

Citation:

Envoyé par imikado

Il ne me semble pas :(
Je developpe en ce moment avec monoDevelopp et on génère des applications mono et Mono (implémentation libre de .net) et non .Net

En effet, ça marche beaucoup mieux de .Net vers Mono que l'inverse.

Citation:

Envoyé par imikado

Par exemple pour la partie graphique je fait du GTK# et non du winforms ou WPF...

Sauf erreur de ma part, tu peux faire du WinForms avec Mono. Bon, tu n'auras pas de designer et ça sera moche car le thème de la distro est pas appliqué, mais ça marche. Pour WPF, il y aurait certaines rumeurs pour son ouverture, mais ça prendrait sûrement pas mal de temps (portage vers OpenGL oblige).

Citation:

Envoyé par imikado

Autre chose, il me semblait avoir lu que c'était ASP.net qui allait être multi plateforme et non .net tout entier... à confirmer

C'est déjà le cas et pleinement opérationnel : http://aspnetwebstack.codeplex.com/. Il y a tout ce qu'il faut pour faire du Web sous Unix en utilisant ASP.NET + Entity. Mais ceci n'est finalement que la première étape de l'ouverture, le reste arrive petit à petit (par exemple, le Net.Core).

Ca prends le temps, mais en tout cas, c'est sur le bon chemin.
06/01/2015, 23h06
tomlev

Citation:

Envoyé par dfiad77pro

(ce qui signifiera une implémentation l’analyse syntaxique et grammaticale, du compilateur roselyn , donc une foultitude de pluggins)

Roslyn fournit déjà l'analyse syntaxique et grammaticale ;)
C'est justement le but de ce nouveau compilateur : ouvrir la "boite noire" qu'est le compilateur en donnant accès à ses mécanismes internes.
Et Roslyn fonctionne déjà sous Linux et MacOS, d'ailleurs je crois qu'OmniSharp se base dessus.

Citation:

Envoyé par Seb33300

Mais quitte à développer une appli .NET, autant utiliser visual studio. Je ne pense pas qu'il puisse une jour exister un équivalant qui puisse rivaliser à tous les niveaux.

C'est sûr que pour le dev .NET, il n'y a pas d'IDE aussi complet que Visual Studio. Mais VS a le gros défaut de ne fonctionner que sous Windows, et vu son architecture (en grande partie basée sur COM), ce n'est pas près de changer. Tout le monde ne veut pas forcément travailler sous Windows... Moi qui suis développeur .NET, je ne me sens pas spécialement attaché à Windows, et je passerai volontiers sous Linux, mais le principal truc qui me retient, c'est Visual Studio (bon, les jeux vidéo aussi :mrgreen:)

Citation:

Envoyé par Seb33300

De toute façon, je doute que les "pro-linux/mac" se tournent un jour vers du développement .NET.

C'est pas si sûr... jusqu'ici, ce qui a bloqué l'adoption de .NET sur Mac et Linux, c'est en grande partie le manque d'outils, et la perception que .NET, c'est Microsoft, et que Microsoft, "çay le mal" :aie:
Beaucoup de gens qui développent dans des environnements non Microsoft reconnaissent les qualités de C# en tant que langage, et seraient peut-être très heureux de pouvoir l'utiliser sur d'autres plateformes que Windows.

Citation:

Envoyé par imikado

Je developpe en ce moment avec monoDevelopp et on génère des applications mono et Mono (implémentation libre de .net) et non .Net
Il y a une grosse différence

Oui et non... le runtime est compatible, et la BCL (Base Class Library) s'efforce de l'être. Si tu fais une appli console qui n'utilise pas de fonctionnalités spécifiques à l'OS, tu devrais pouvoir la faire tourner sans mal sous Windows, Linux et Mac.

Par contre, pour ce qui est des frameworks d'UI, c'est une autre histoire... Tu ne feras jamais tourner une appli WPF sous un autre OS que Windows. Avec Windows Forms, c'est un peu mieux : dans mon ancienne boite, on développait une grosse appli assez complexe en Windows Forms, et un collègue a réussi à la faire tourner (sans recompiler) sous Linux avec Mono et Wine (il y avait quelques petits problèmes, mais dans l'ensemble ça marchait assez bien). Quant à GTK#, ça peut tourner sous Windows, il faut juste qu'il soit installé (ou déployé avec l'application)

Citation:

Envoyé par imikado

Et un autre exemple: je compile sur mon Linux, et l'application ne fonctionne pas sur mon windows où mono n'est pas installé :(

Ça c'est pas normal... Les exécutables générés par le compilateur C# de MS peuvent être exécutés avec Mono, et en principe ça devrait aussi marcher dans l'autre sens. Es-tu sûr que c'était parce que Mono n'était pas installé ? Il y a peut-être une autre raison...

Citation:

Envoyé par imikado

Autre chose, il me semblait avoir lu que c'était ASP.net qui allait être multi plateforme et non .net tout entier... à confirmer

C'est sûr que certaines parties de .NET ne seront probablement jamais multi-plateformes :
- soit parce que ça n'aurait pas de sens (System.Management par exemple, pour accéder à WMI, donc très spécifique à Windows)
- soit parce que ça demanderait un travail énorme d'adaptation (par exemple Windows Forms, qui repose lourdement sur Win32, ou WPF qui repose beaucoup sur DirectX et un peu sur Win32)

Pour le reste, pas de problème a priori. Ce n'est pas limité à ASP.NET ; les packages de .NET Core sont utilisés dans ASP.NET, mais sont aussi utilisables pour d'autres types d'application.
06/01/2015, 23h24
Graffito

Citation:

Anthyme : gnome a bien une dépendance sur mono donc des linuxiens qui font du C# il y en a depuis déjà pas mal de temps ;-)

Es-tu sûr ?
Cela voudrait dire que Mono serait installé en natif sur des distributions intégrant Gnome (par exemple, CentOs de Red Hat) !
06/01/2015, 23h39
imikado

1 pièce(s) jointe(s)

Pas proposé dans monoDevelopp :(
Pièce jointe 165514

Et oui, effectivement le problème se pose pour les application avec interface (ce qui est mon cas)
Et donc, actuellement mon appli .net utilisant gtk# (pas le choix) elle ne fonctionne pas nativement sur windows :(

Mais je ne suis pas sur qu'en compilant une appli .net sous windows, celle-ci fonctionne nativement sous linux non plus ;)
Avec l'ouverture de .net et ce changement de cap, mono devrait y gagner en portabilité :)
07/01/2015, 00h34
tomlev

Citation:

Envoyé par imikado

Mais je ne suis pas sur qu'en compilant une appli .net sous windows, celle-ci fonctionne nativement sous linux non plus ;)

Bah si, justement, c'est ce que je te disais, et je l'ai déjà vérifié... à condition bien sûr qu'elle n'utilise rien de spécifique à Windows (ou alors en utilisant Wine)
07/01/2015, 07h16
imikado

J'essaierai aujourd'hui, mais on parle bien d'une application graphique (wpf/winforms...) pas console ?

Utiliser wine ce n'est pas natif, désolé ;)
07/01/2015, 10h05
tomlev

Citation:

Envoyé par imikado

J'essaierai aujourd'hui, mais on parle bien d'une application graphique (wpf/winforms...) pas console ?

A la base je parlais d'une appli console. WPF ou WinForms n'existent pas sous Linux, donc ça peut pas marcher... mais avec GTK# ça doit le faire.

Citation:

Envoyé par imikado

Utiliser wine ce n'est pas natif, désolé ;)

Oui je sais, c'est de la triche ;)
07/01/2015, 11h00
imikado

1 pièce(s) jointe(s)

Citation:

Envoyé par tomlev

A la base je parlais d'une appli console. WPF ou WinForms n'existent pas sous Linux, donc ça peut pas marcher... mais avec GTK# ça doit le faire.

Oui il faut préciser :que console, ce qui limite pas mal l'exercice :)

Et pour GTK#, dans mon visual studio:
Pièce jointe 165547
07/01/2015, 11h23
tomlev

Citation:

Envoyé par imikado

Et pour GTK#, dans mon visual studio:

Oui je sais bien, mais c'est pas la question... Là tu confonds l'IDE et le compilateur. Visual Studio n'a pas de support natif pour GTK# (quoiqu'il existe peut-être des plugins pour ça), donc tu n'as pas de designer, mais au final, tout ce que fait le designer, c'est générer du code... une fois que tu as le code, tu peux le compiler indifféremment avec le compilateur MS (csc.exe) ou Mono (mcs.exe), et l'exécuter sous Mono ou .NET.
07/01/2015, 12h30
landry161

Citation:

Envoyé par redcurve

Surtout pas Eclipe ce soft est une horreur

Hum par moment ouais
07/01/2015, 15h46
dfiad77pro

Citation:

Envoyé par tomlev

Roslyn fournit déjà l'analyse syntaxique et grammaticale ;)
C'est justement le but de ce nouveau compilateur : ouvrir la "boite noire" qu'est le compilateur en donnant accès à ses mécanismes internes.
Et Roslyn fonctionne déjà sous Linux et MacOS, d'ailleurs je crois qu'OmniSharp se base dessus.

ah oui grosse bêtise de ma part :mouarf:
Cela dit ça reste une implémentation de roselyn au sein de l'IDE. C'est vrai que ça va être un énorme avantage de ce coté.
21/01/2015, 14h38
Cubitouch

.NET Core

Pour ce qui est de .NET Core, j'ai cru comprendre que c'était bien plus qu'un simple fork ayant pour cible le cross-plateforme...
Selon leurs propres termes, c'est une version allégée et optimisée pour le cloud de .NET (pas de WPF/WinForm, System.Web saute et est refondu, ...), et, au passage, ils se donnent comme objectif d'être compatible avec Mac et Linux pour toucher plus de développeurs.