Discussion :

[Gluups]

Bonjour tout le monde,

En me lançant après quelques semaines d'interruption sur une application MVC, je constate que les "échaffaudages" qui jusque là préparaient l'application aux petits oignons presque automatiquement, à présent fournissent quelque chose que le compilateur passe tout son temps à houspiller.

J'en déduis donc qu'il y a une migration à effectuer. Le compilateur indique erreur par erreur quoi faire, et puis à trois erreurs de la fin il me dit de supprimer un objet qu'il m'a fait créer quinze secondes avant, donc la raison dit de tout arrêter.

Effectivement,
je trouve "Learn to upgrade from ASP.NET MVC and Web API to ASP.NET Core MVC | Microsoft Learn".

J'aurais juré que mes développements MVC étaient basés sur .Net Core depuis belle lurette, pourtant cette page ne porte pas de date, ça devrait encourager à considérer qu'elle est d'actualité ?


Alors donc je me suis bien engagé sur la porte d'entrée, mais je me prends la porte suivante en pleine figure. En effet, je me suis trompé à installer le runtime au lieu du SDK, ce qui fait qu'ensuite, une fois le SDK téléchargé et décompressé, quand je double-clique sur dotnet qui est le seul exécutable, je vois un cadre de fenêtre qui apparaît un vingtième de seconde à peu près sur toute la surface de l'écran, et puis c'est tout, fin de traitement, même pas un commentaire.

Ah pourtant, dotnet-list-sdks me trouve bien le 3.1.426 que je viens de télécharger (avant il y avait déjà le 8 et le 9).

C'est aussi rapide que ça à installer ?
Ou je me suis mélangé les pinceaux ?

Parce que là je n'en suis qu'aux prérequis, après il y a trois chapitres qui viennent, donc il vaut mieux être sûr que l'installation s'est bien passée.

Puisque la doc dit d'installer le SDK, dans le gestionnaire de packages NuGet je cherche "Microsoft.EntityFrameworkCore.SDK", et là, certes on ne me trouve qu'un résultat ce qui est un progrès par rapport à d'autres recherches, mais il s'appelle "HEM.Common.Sdk.Persistance.EfCore"

Faut-il comprendre que l'un implémente l'autre ?

Je joue la prudence parce que le compilateur m'a dit ouais ouais tout va bien je gère, et puis à deux pas de la fin je le prends à suivre le chemin à rebours, et là ça me fait hésiter.

***
Du coup apparaît en filigrane une autre question : le forum porte le nom de la plateforme de départ, et je me lance dans une migration vers une autre plateforme. Je ne me suis pas trompé dans le choix du forum, au moins ?

***
Après avoir validé le message je vois en bas de page des questions sur .Net Core MVC qui datent de 2019.

"M'avait bien semblé."

On dirait que ça aurait été une bonne idée de mettre une date sur la doc, et que je vais devoir lancer une nouvelle recherche sur le critère "migration".

Parce que j'imagine mal les "échafaudages" changer de plateforme cible sans crier gare et sans une raison sous-jacente ?

[Gluups]

Plus précisément, voilà ce que me dit la compilation, en persistant après désinstallation et réinstallation de MVC :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Installation de l’outil dotnet-scaffold...
C:\Program Files\dotnet\dotnet.exe scaffold aspnet mvccontroller-crud --model Categorie --controller CategoriesController --dataContext TestCat31Context --dbProvider sqlserver-efcore --views --project "C:\Projects Visual Studio\Web\TestCat31\TestCat31\TestCat31.csproj"
Initializing scaffolding model...
Unhandled exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Le fichier spécifié est introuvable.
File name: 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.DotNet.Scaffolding.Roslyn.Services.MSBuildProjectService.GetProjectCapabilities(Boolean refresh)
   at Microsoft.DotNet.Tools.Scaffold.AspNet.Common.ClassAnalyzers.GetProjectInfo(String projectPath, ILogger logger) in /_/src/dotnet-scaffolding/dotnet-scaffold/AspNet/Common/ClassAnalyzers.cs:line 205
   at Microsoft.DotNet.Tools.Scaffold.AspNet.ScaffoldSteps.ValidateEfControllerStep.GetEfControllerModelAsync(ScaffolderContext context, EfControllerSettings settings) in /_/src/dotnet-scaffolding/dotnet-scaffold/AspNet/ScaffoldSteps/ValidateEfControllerStep.cs:line 213
   at Microsoft.DotNet.Tools.Scaffold.AspNet.ScaffoldSteps.ValidateEfControllerStep.ExecuteAsync(ScaffolderContext context, CancellationToken cancellationToken) in /_/src/dotnet-scaffolding/dotnet-scaffold/AspNet/ScaffoldSteps/ValidateEfControllerStep.cs:line 96
   at Microsoft.DotNet.Scaffolding.Core.Scaffolders.Scaffolder.ExecuteAsync(ScaffolderContext context) in /_/src/dotnet-scaffolding/Microsoft.DotNet.Scaffolding.Core/Scaffolders/Scaffolder.cs:line 68
   at Microsoft.DotNet.Scaffolding.Core.CommandLine.CommandLineExtensions.<>c__DisplayClass1_0.<<ToCommand>b__0>d.MoveNext() in /_/src/dotnet-scaffolding/Microsoft.DotNet.Scaffolding.Core/CommandLine/CommandLineExtensions.cs:line 104
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.InvokeAsync(ParseResult parseResult, CancellationToken cancellationToken)

La ligne System.IO.FileNotFoundException me parle de File name: 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a',

et cela, que le projet cible .Net 9 ou .Net 8.

C'est arrivé à peu près en même temps que pour développer de l'Angular c'est devenu la croix et la bannière parce que le modèle a été mis à niveau vers .Net 10, sans me demander ce que j'en pense. Donc pour chaque nouveau projet il faudrait récupérer les références d'un ancien projet, taper install, le truc complètement nasodigital.

Je précise que .Net 10 est installé aussi bien en SDK qu'en runtime, c'est juste Visual Studio 2022 qui ne le reconnaît pas.

Une façon de me dire qu'il faut mettre Visual Studio 2022 à la poubelle ? Sauf pour développer un "Hello World" ...

[Gluups]

Bon, pendant mon absence (et à cette époque je ne devais pas être le seul), voilà ce qui s'est passé :
- Dotnet 10 a été publié ; si Windows Update est configuré pour installer les mises à jour automatiquement, Dotnet 10 a donc été installé
- Sauf à se donner le mal d'une précision contraire (en sélectionnant la version), Microsoft.EntityFramework.Core cible systématiiquement la dernière version de .Net, et Visual Studio 2022 ne la charge pas correctement, il en résulte donc une erreur de compilation.

On peut toujours développer en MVC sous Visual Studio 2022, mais sauf acrobaties guère garanties, pour faire ça en obtenant un développement fluide il convient de désinstaller .Net 10

Microsoft conseille, pour le développement avec .Net 10, l'installation de Visual Studio 2026, comptez pour cela quelques dizaines de giga-octets de téléchargement.

J'ai vu proposer une extension / des explications, pour créer un projet ciblant .Net 10.

Mais attention : créer un projet sous .Net 10, certes ça doit pouvoir se faire, mais si ce projet doit faire référence à EntityFrameworkCore, il y a intérêt à bien tester le processus avant de dire que ça fonctionne sous Visual Studio 2022.