Le fichier project.lock.json doit-il être vérifié dans le contrôle de source ? (ASP.NET Core 1.0)

Question

En utilisant ASP.NET Core 1.0, la meilleure pratique consiste-t-elle à vérifier dans le fichier projet.lock.json dans le contrôle de source ?

Answer 1

Réponse courte : Non, project.lock.file ne doit pas être vérifié dans le contrôle de source - vous devez configurer le système de contrôle de version pour l'ignorer (c'est-à-dire l'ajouter à .gitignore si vous utilisez git).

Réponse longue : Le project.lock.json contient un instantané de l'arbre des dépendances du projet - pas seulement les paquets listés dans les sections "dependencies", mais aussi toutes les dépendances résolues de ces dépendances, et ainsi de suite. Mais ce n'est pas comme le Gemfile.lock . Contrairement à Gemfile.lock, project.lock.json n'indique pas à dotnet restore les versions exactes des paquets à restaurer - elle est simplement écrasée. En tant que tel, il doit être traité comme un fichier de cache et ne jamais être vérifié dans le contrôle de source.

Si vous l'enregistrez dans le système de contrôle de version, il est très probable qu'il se trouve sur une autre machine :

• dotnet pensera que tous les paquets sont restaurés, mais en fait certains paquets peuvent être manquants et la construction échouera, sans indiquer au développeur de lancer dotnet restore
• project.lock.json sera écrasé lors de l'utilisation de l'application dotnet restore et, dans la plupart des cas, elle sera différente de la version stockée dans le contrôle de la source. Elle sera donc modifiée dans presque toutes les livraisons
• project.lock.json causera des conflits lors de la fusion

Answer 2

En fait, il est parfois nécessaire de livrer le fichier project.lock.json dans git.

Vérifier le json de votre projet

Pour les mêmes raisons, il vous indique les dépendances que vous avez utilisées. Dites-le :

1. Moi, en tant que développeur, je travaille sur une application, je déteste chaque fois mettre à jour les paquets, alors j'ajoute une dépendance de paquet à nuget paquet X = 1.*
2. Je restaure le paquet et j'obtiens la version 1.2.4
3. Le créateur du paquet a juste fait une erreur très stupide, il a cassé quelque chose alors qu'il essayait juste de faire une correction et de sortir la 1.2.5.
4. La deuxième personne se retire (ou, pire encore, la construction de la libération se met en marche).
5. La personne 2 restaure et obtient la version 1.2.5.
6. La personne 2 exécute votre application et constate qu'elle est défectueuse.
7. La personne 2 commence à déboguer et pense qu'il doit y avoir un bogue dans le logiciel.

À cette étape, 7 Person 2 aurait pu voir dans git que son fichier lock a été modifié et qu'une version plus récente d'une bibliothèque a été téléchargée, qui n'a été testée par aucun des autres développeurs !

Inconvénients

L'inconvénient de vérifier ce fichier est que vous risquez d'obtenir de nombreux conflits de fusion lors des mises à jour continues des paquets.

Solution alternative

N'utiliser que des dépendances de versions dures (c'est assez difficile pour nuget). Et ne mettre à jour manuellement vers une version plus récente que de temps en temps.

Inconvénients

• Cela ne fonctionne pas si vous construisez une bibliothèque pour que d'autres personnes puissent l'utiliser, puisque vous les épinglez à une certaine version de vos dépendances.
• Les dépendances des dépendances sont toujours résolues automatiquement, donc si vous ne les spécifiez pas vous-même, vous ne pouvez pas garantir qu'il y a une version sur dotnet restore

Conclusion

Si vous voulez éviter les citations du type "fonctionne sur ma machine" et l'enfer de la mise à jour manuelle constante vers une version plus récente : Vérifier le fichier project.lock.json.

Et aussi construire un CI/Release build check pour tester si ce fichier n'a pas été modifié par rapport à git, avant de le publier (si votre logiciel est très critique) !

Si ce n'est pas un problème et que la mise à jour automatique (vers un paquet potentiellement cassé) n'est pas non plus un gros problème, vous ne voudrez peut-être pas livrer votre project.lock.json.

Answer 3

Non, il s'agit simplement d'un verrouiller le fichier Vous ne devez donc jamais l'enregistrer lorsqu'un fichier de verrouillage existe (sauf si le programme qui l'a verrouillé veut l'enregistrer dans le contrôle des sources, auquel cas, excluez votre fichier de verrouillage !)