IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

.NET Core : que pensez-vous de l'abandon du project.json et le retour du format .csproj ?
Êtes-vous d'accord avec l'orientation de Microsoft ?

Le , par Hinault Romaric

35PARTAGES

6  0 
Microsoft avait annoncé il y a quelques mois son intention d’abandonner le fichier project.json introduit par .NET Core pour retourner au format .csproj. Ceci, à cause de l’expérience avec le project.json qui a été un échec. Cela s’est concrétisé avec la récente présentation des outils pour .NET Core dans Visual Studio 15, qui est actuellement disponible en preview 5.

Pourquoi le fichier project.json avait été adopté à la place du .csproj

.NET Core a été conçu pour fonctionner sur Windows, Linux et Mac. La volonté de Microsoft est de permettre aux développeurs de créer des applications .NET en utilisant leur système d’exploitation préféré et l’EDI de leur choix.

Le format .csproj n’était pas adapté pour atteindre ces objectifs. Ce dernier est extrêmement lié à MsBuild, qui n’était pas open source et cross-platform. C’est un fichier difficile à interpréter à l’œil, verbeux et laborieux à éditer. De plus, il est une source de conflits pour les équipes qui utilisent un gestionnaire de versions, car ce dernier est édité à chaque ajout d’un fichier au projet.

Le fichier project.json a apporté une solution à ces problèmes :
  • plus de spécifications des fichiers dans le fichier de projet ;
  • un fichier facilement compréhensible et modifiable sans avoir recours à un IDE ;
  • la compilation cross-platform ;
  • et bien plus.


Toutefois, l’adoption du project.json a introduit de nombreux défis pour les développeurs de Microsoft.

Pourquoi le retour du format .csproj

Le fichier project.json bien qu’étant très adapté pour les projets Web (le format json étant devenu quasiment incontournable dans le développement Web), présente cependant des limites pour son extension à d’autres projets .NET.

En effet, Microsoft ambitionne de généraliser le développement cross-platform à d’autres projets .NET, en faisant de .NET Core le socle pour :
  • le développement d’applications ASP.NET (ce qui est déjà le cas) ;
  • le développement d’applications console ;
  • le développement des bibliothèques ;
  • le développement d’applications Windows universelles ;
  • et même le développement d’applications Android et iOS avec Xamarin.


De ce fait, le project.json devait être étendu à l’ensemble de ces projets. Ce qui allait entrainer de gros efforts, qui allaient toucher l’ensemble des projets dans Visual Studio, Xamarin et même les partenaires de Microsoft.

Pour éviter cela, la firme a décidé de retourner au fameux .csproj. Toutefois, la firme a tiré parti des avantages apportés par le fichier project.json. Elle promet donc que le nouveau .csproj sera assez similaire au project.json, ne listera pas les fichiers sources et sera facilement modifiable dans Visual Studio qui offrira notamment l’IntelliSense.

Le retour du format .csproj, quelle conséquence pour le cross-platform

Dans son billet de blog, Microsoft promet que le fichier .csproj sera facilement éditable, surtout avec Visual Studio. Qu’en est-il des autres éditeurs : Visual Studio Code, Vim, Atom, Sublime, etc ? L’adoption d’un format ouvert et populaire comme json rendait par défaut le fichier project.json compatible avec tous ces outils et facile à lire pour les développeurs. Alors que le .csproj est propre à Microsoft.

Et vous ?

Que pensez-vous du retour du format .csproj ?

Êtes-vous d’accord avec l'orientation de Microsoft ?

Le .csproj est-il adapté pour le cross-plaform et les autres EDI ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de jopopmk
Membre expert https://www.developpez.com
Le 21/10/2016 à 15:22
Je suis vraiment dépassé par ces considérations :
- j'ai du mal à comprendre le souci d'un format ou l'autre, tant que les specs sont accessibles,
- je trouve pas le csproj particulièrement compliqué à comprendre,
- parser les info de projet depuis un json me parait pas un travail insurmontable quand bien même il impacterait de nombreux logiciels.

Du coup qu'en pensé-je ? Pas grand chose.
Oui, vous pouvez me remercier pour cette intervention constructive
1  0 
Avatar de gb_68
Membre confirmé https://www.developpez.com
Le 21/10/2016 à 16:15
Citation Envoyé par Hinault Romaric Voir le message
Ce dernier est extrêmement lié à MsBuild, qui n’est pas open source et cross-platform.
Ce dernier point n'est plus exacte depuis mars 2015 .

Microsoft-rend-disponible-en-open-source-le-moteur-de-MSBuild-son-outil-de-compilation
https://github.com/Microsoft/msbuild
1  0 
Avatar de LapinGarou
Membre confirmé https://www.developpez.com
Le 21/10/2016 à 16:13
Tant que le contenu est lisible pas de soucis
Un *.csproj n'est qu'un *.xml dont on a changé l'extension, où est le problème ? (En tous cas jusqu'à VS2K13, je ne suis pas encore passé au 2015)
0  0 
Avatar de Hinault Romaric
Responsable .NET https://www.developpez.com
Le 21/10/2016 à 16:33
Effectivement. J'ai corrigé le sujet. Merci.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 21/10/2016 à 16:51
Dans le principe j'aimais bien l'idée de s'affranchir de MSBuild; bien que très puissant, c'est une usine à gaz un peu dégueulasse, et je trouvais le format project.json assez "rafraichissant".

Cela dit, il faut être pragmatique; ça aurait pris des années pour que tous les outils soient mis à jour pour utiliser project.json, autant capitaliser sur ce qui existe. Le format csproj a été très simplifié pour .NET Core, la gestion des packages NuGet est intégrée, le multi-targeting aussi, et on n'a plus besoin de lister explicitement tous les fichiers du projet. Bref, c'est pas forcément la solution dont on aurait rêvé, mais c'est simple et fonctionnel. Je pense donc que c'était une bonne décision.
0  0 
Avatar de skyzoboy
Candidat au Club https://www.developpez.com
Le 24/10/2016 à 12:22
Je suis vraiment dépassé par ces considérations :
- j'ai du mal à comprendre le souci d'un format ou l'autre, tant que les specs sont accessibles,
- je trouve pas le csproj particulièrement compliqué à comprendre,
- parser les info de projet depuis un json me parait pas un travail insurmontable quand bien même il impacterait de nombreux logiciels.
L'avantage d'avoir une extension standard, c'est que les IDE savent faire des choses avec: coloration syntaxique, intellisense, formatage/minification, validation de format, etc...
0  0 
Avatar de jopopmk
Membre expert https://www.developpez.com
Le 24/10/2016 à 14:53
Citation Envoyé par skyzoboy Voir le message
L'avantage d'avoir une extension standard, c'est que les IDE savent faire des choses avec: coloration syntaxique, intellisense, formatage/minification, validation de format, etc...
Y'a beau avoir une extension .csproj (ou .vbproj) ça reste du XML. C'est donc très bien colorisé par la plupart des éditeurs et on peut facilement valider la syntaxe via un XSD. Pour les manip' sur les arbres, du XML ou du JSON c'est kifkif. Le vrai souci c'est de définir des spec précises, de les diffuser et de s'y tenir (3 choses pour lesquelles Crosoft n'est pas particulièrement connu).
0  0