Affichage des articles dont le libellé est Enfer du DotNET. Afficher tous les articles
Affichage des articles dont le libellé est Enfer du DotNET. Afficher tous les articles

Développement .NET MAUI stabilité de la plateforme de développement

Je développement avec Visual Studio Community 2022 et MAUI le successeur de Xamarin ... Et je vois devant moi la plateforme prendre des initiatives comme ajouter des Using fantaisistes pour compléter le code que je suis en train d'écrire.

Je suis surpris, je trouve cela un peu trop intrusif d'autant que vous ajoutez un using par ci par là mais la plateforme joue aussi beaucoup avec les packages qu'elle installe aussi automatiquement en fonction des projets que vous ouvrez.

Alors tout ceci est-il bien stable ? C'est une question dont je viens d'avoir la réponse.

Trouble shooting using MAUI plateforme

Voici la réponse à la question, la plateforme de développement Microsoft .NET MAUI est-elle stable ?

La plateforme de développement Microsoft .NET MAUI est-elle stable ?
La plateforme de développement Microsoft .NET MAUI est-elle stable ?

Cela fait déjà un petit moment que je trouve les initiatives de la plateforme ... comment dire ... mal à propos. Et ce matin voilà ça y est c'est planté !

Ce matin, j'ai bien peur de retomber dans :

L'Enfer du DotNET !

Alors trouvons des solutions au maintient d'une plateforme stable.

Error dans Xamarin Tools

Pourquoi Xamarin ? Je croyais que l'on en avait plus besoin...

1 - C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.46\tools\Xamarin.Android.Aapt2.targets

Une erreur avec Xamarin, alors c'est curieux parce qu'il est stipulé lorsque vous débutez MAUI que c'est le successeur de Xamarin mais qui n'a pas besoin de Xamarin d'ailleurs quand vous installez le Développement .NET MAUI Xamarin est facultatif certainement pour migrer des anciens projets Xamarin vers MAUI.

Xamarin est-il nécessaire à la MAUI Plateforme ?
Xamarin est-il nécessaire à la MAUI Plateforme ?

Une fois de plus je vais trouver la solution mais c'est navrant de constater que ce n'est pas encore sec sec sec tout ça. Il y a surement encore des liens trop ténus avec Xamarin et sa foultitude de tools qui ne fonctionnent pas.

Bien sûr, je vais vous trouver une solution, stay tude.

Erreur NU1105 - Impossible de lire les informations du projet

Voici cette nouvelle instabilité de ma plateforme de développement, en général quand ce genre de message apparaît alors que vous ne pensez pas avoir fait quoi que ce soit, c'est au moins la demi-journée pour trouver la correction sauf si vous avez de la chance. 

Impossible de lire les informations relatives au projet pour 'MauiAppToolkit' :
La séquence contient plusieurs éléments ...

Voici l'erreur du jour, elle je vous assure elle est coton car la solution n'est pas évidente. J'ai un fichier project.assets.json qu in'est pas généré correctement.

Hummm l'erreur Visual Studio qu'elle pue la mmm
Hummm l'erreur Visual Studio qu'elle pue la mmm

Alors que s'est-il passé ? D'après moi c'est d'avoir ouvert la solution avec Visual Studio 2019 qui a commencé à bricoler tenter de faire des mise à jour alors que la Solution MAUI ne peut s'ouvrir qu'avec Visual Studio 2022 !

Je supprime bien sur les .\bin et .\obj rien n'y fait.

Je recherche du côté de la suppression des NuGets dans les répertoire :

C:\Users\Mabyre\.nuget\

Je supprime Tout !

Je regarde dans :

C:\Program Files (x86)\Microsoft SDKs\NuGetPackages

Rien n'a à voir avec Maui ou Community, je ne supprime pas !

C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages

Il n'y a rien là dedans !

Alors je vais du côté de : 

Outils -> Options -> Gestionnaire de package NuGet -> Général

Gestionnaire de packages Nugets

Je clique sur :  Effacer tout le stockage NuGet. C'est peut être ça qui à corrigé le problème ...

Dans la fenêtre de sortie :

Effacement du cache HTTP NuGet : C:\Users\Mabyre\AppData\Local\NuGet\v3-cache
Effacement du dossier des packages globaux NuGet : C:\Users\Mabyre\.nuget\packages\
Effacement du cache temporaire NuGet : C:\Users\Mabyre\AppData\Local\Temp\NuGetScratch
Effacement du cache des plug-ins NuGet : C:\Users\Mabyre\AppData\Local\NuGet\plugins-cache
Ressources locales effacées.
========== Fin ==========

Je créé une nouvelle solution en ouvrant directement le fichier .csproj. Je quitte en sauvegardant la solution. 

Puis, une idée de génie je tente d'exécuter quand même la solution malgré les erreurs, voilà ma solution devant moi en train de s'exécuter. Du coup j'aimerais remettre la solution dans le répertoire racine du projet mais voilà :

Error AndroidManifest.xml

Bon voilà c'est corrigé :

GitHub - Mabyre - MauiAppToolkit

Crash de la Plateforme de développement MAUI

Voilà le problème précédent corrigé, qu'un nouveau crash se produit ...

Erreur : ApplicationId 'com.companyname.mauicameramauisample' was not a valid GUID. Windows apps use a GUID for an application ID instead of the reverse domain used by Android and/or iOS apps. Either set the <ApplicationIdGuid> property to a valid GUID or use a condition on <ApplicationId> for Windows apps. MauiCameraMauiSample C:\Program Files\dotnet\packs\Microsoft.Maui.Resizetizer.Sdk\7.0.86\targets\Microsoft.Maui.Resizetizer.targets 655

C:\Program Files\dotnet\packs\Microsoft.Maui.Resizetizer.Sdk\7.0.86\targets\Microsoft.Maui.Resizetizer.targets(655,9): error : ApplicationId 'com.companyname.mauicameramauisample' was not a valid GUID. Windows apps use a GUID for an application ID instead of the reverse domain used by Android and/or iOS apps. Either set the <ApplicationIdGuid> property to a valid GUID or use a condition on <ApplicationId> for Windows apps.

Une petite fenêtre très sympathique VCManagePackage :

Allé encore, cette fois également ça sent mauvais... Bon comme il y a une mise à jour Visual Studio et bien allons y mettons à jour 17.6 en 17.7 je crois.

Erreur NETSDK1112 le pack de runtime pour Microsoft.NETCore.App.Runtime.win-x64 n'a pas été téléchargé. Essayez d'exécuter une restauration NuGet avec le RuntimeIdentifier 'win-x64'. MauiCameraMauiSample C:\Program Files\dotnet\sdk\7.0.304\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 448

Un petit coup de PowerShell :

PS>dotnet restore --runtime win-x64

L'erreur Erreur NETSDK1112 est corrigé mais pas l'autre. Pour corriger l'autre j'ai du ajouter :

<ApplicationIdGuid>dafdd4e2-67de-4a3e-9f4f-196e13fb1bd1</ApplicationIdGuid>

Dans le fichier projet .csproj de la solution... rien de moins que de bricoler le fichier .csproj à la mimine.

Erreur AMM0000

Et cela continue !

Erreur AMM0000 uses-sdk:minSdkVersion 19 cannot be smaller than version 21 declared in library C:\Users\Mabyre\Documents\Visual Studio 2022\Samples\MAUI\MauiAppToolkit\MauiAppToolkit\obj\Debug\net7.0-android\lp\133\jl\AndroidManifest.xml as the library might be using APIs not available in 19

Suggestion: use a compatible library with a minSdk of at most 19,

or increase this project's minSdk version to at least 21,

or use tools:overrideLibrary="androidx.security" to force usage (may lead to runtime failures)

Directory 'obj\Debug\net7.0-android\lp\133' is from 'androidx.security.security-crypto.aar'. MauiAppToolkit C:\Users\Mabyre\Documents\Visual Studio 2022\Samples\MAUI\MauiAppToolkit\MauiAppToolkit\obj\Debug\net7.0-android\AndroidManifest.xml 46

J'avoue cela me fatigue un peu ...

Du coup j'ai supprimé la ligne :

<uses-sdk />

Du fichier :

\MauiAppToolkit\Platforms\Android\AndroidManifest.xml

Et ça fonctionne à nouveau.

.NET 6.0 & .NET 7.0

Ce matin, je travaille sur mon MAUI Application Toolkit pas de soucis. Et puis, je ne sais pour qu'elle raison saugrenue, j'ai eu envie d'essayer le projet suivant :

https://github.com/henduck/MAUINewsApp.git

Je clone, j'ouvre la solution, je laisse la génération se dérouler et

BOOUUUUMMMMMMM !!!

Erreur	NETSDK1005	Le fichier de composants '\Visual Studio 2022\Samples\MAUI\MauiAppToolkit\MauiAppToolkit\obj\project.assets.json' n'a aucune cible pour 'net7.0-windows10.0.19041.0'
Erreur NETSDK1005 Le fichier de composants '\Visual Studio 2022\Samples\MAUI\MauiAppToolkit\MauiAppToolkit\obj\project.assets.json' n'a aucune cible pour 'net7.0-windows10.0.19041.0'

Message d'erreur :

Erreur NETSDK1005 Le fichier de composants '\MauiAppToolkit\obj\project.assets.json' n'a aucune cible pour 'net7.0-windows10.0.19041.0'. Vérifiez que la restauration s'est exécutée et que vous avez inclus 'net7.0-windows10.0.19041.0' dans TargetFrameworks pour votre projet. MauiAppToolkit C:\Program Files\dotnet\sdk\7.0.304\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets

Ça fait toujours bien dans le SEO du post de mettre le message d'erreur !

Je suppose que l'erreur fut générée par la restauration du projet en .NET 6.0 alors que le projet MauiAppToolkit est déjà en .NET 7.0.

Je découvre :

GitHub Redth - dotnet-maui-check

J'exécute tout ce qu'il faut ça prend du temps plusieurs minutes :

Exécution de .NET MAUI Check
Exécution de .NET MAUI Check 

Dommage on dirait pourtant que tout va bien mais rien à faire :

Erreur NETSDK1005 Le fichier de composants 'C:\Users\Mabyre\Documents\Visual Studio 2022\Samples\MAUI\MauiAppToolkit\MauiAppToolkit\obj\project.assets.json' n'a aucune cible pour 'net7.0-android'. Vérifiez que la restauration s'est exécutée et que vous avez inclus 'net7.0-android' dans TargetFrameworks pour votre projet. MauiAppToolkit C:\Program Files\dotnet\sdk\7.0.304\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 266

Et puis à force de lire ce message d'erreur 'restore' m'enfin oui bien sûr il y a la commande :

Commande PowerShell > DotNET Restore

PS C:\Users\Mabyre\Documents\Visual Studio 2022\Samples\MAUI\MauiAppToolkit>dotnet restore

Cela prend du temps mais au bout PowerShell me répond "Restauration effectuée en 3,55 min et cette fois cela y est mon application fonctionne à nouveau.

Have a nice day! I'll go to the beach!

Échec inattendu de la tâche "GenerateJavaStubs" - Solution

Mais qu'elle est cette erreur, comment trouver la solution. Ce matin je repars sur cette erreur "Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de 260 caractères et le nom du répertoire moins de 248 caractères." Erreur que j'ai détaillé dans le post précédent.

Gravité Code Description Projet Fichier Ligne État de la suppressionErreur  Échec inattendu de la tâche "GenerateJavaStubs".
System.IO.PathTooLongException: Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de 260 caractères et le nom du répertoire moins de 248 caractères.
   à System.IO.LongPathHelper.Normalize(String path, UInt32 maxPathLength, Boolean checkInvalidCharacters, Boolean expandShortPaths)
   à System.IO.Path.NewNormalizePath(String path, Int32 maxPathLength, Boolean expandShortPaths)
   à System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
   à System.IO.Path.GetFullPathInternal(String path)
   à System.IO.Path.GetFullPath(String path)
   à Xamarin.Android.Tasks.GenerateJavaStubs.Run(DirectoryAssemblyResolver res)
   à Xamarin.Android.Tasks.GenerateJavaStubs.Execute()
   à Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   à Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() Todo.Android

On se croirait revenu aux temps du DOS de Windows qui n'était pas capable de gérer des chemins de fichier de plus de 256 caractères. Mais d'ailleurs, le peut-il aujourd'hui ? ;-) LoL.

Mais cette fois j'ai l'idée, je lis plus attentivement le message d'erreur. Comme quoi "il faut lire" comme dirait Dany Boon et la nuit porte conseil. Je rapatrie mon projet à la racine du disque dur et devinez quoi ? Ca fonctionne !

Solution

Le chemin (path) de votre projet est trop long ... Créez un répertoire plus proche de la racine du disque dur.

Et voilà :

Exécution du Sample Todo de Xamarin sur mon emulateur Android Nougat 7.5
Incroyable non ? Oui mais avant de la trouver celle-la j'ai bien galéré alors c'est cadeau, n'hésitez pas à laisser votre commentaire ou à cliquer sur le côté dans vous savez quoi ... ;-)

Have fun!

Xamarin, ASP.NET Core où sont les NuGets c'est la stupéfaction !

Vous avez sauté le pas de l'ASP.NET Standard et vous êtes maintenant avec ASP.NET Core vous n'hésitez plus maintenant que votre Visual Studio est configuré avec les émulateur d'Android à générer des applications pour Xamarin mais vous avez encore un problème avec les packages NuGets et là ... C'est la stupéfaction !

En effet, je prend le temps d'écrire ce post car je suis maintenant obligé de résoudre ce problème ! Je m'intéresse aux Samples avec Xamarin. Par le passé j'avais écris ASP.NET Core où sont les NuGets ?

https://forums.xamarin.com/
Xamarin Forum
Maintenant si je créé un nouveau projet Xamarin avec mon Visual Studio, les Nugets sont dans :

C:\Users\Xxxx\.nuget\packages

C'est la CATA Totale !

En effet les Nugets dépendent du type d'application dépendent également de leur propre version, ils sont donc très fortement liés au projet et ne peuvent en aucun cas être communs à tous les projets. Je ne comprends pas totalement pourquoi ma plateforme de développement est configurée ainsi Est-ce lors de l'installation de Visual Studio ?

Il faut trouver le moyen de mettre ces foutus NuGets par projet ... Je pars donc à la recherche d'une solution.

I'll be back!

Recherche rapide de solution, on me dit :

Comment puis-je mettre à jour mes NuGets ?

Et quand je fais ça, j'obtiens :


Visual Studio -> Outils -> Extensions et mises à jour -> mises à jour -> Error 503 Service Unavailable

Error 503 Service Unavailable

Whaou la merde !!!

En bas de la fenêtre je vois "Changer les paramètres de vos extensions et mise à jour" je clique dessus ...

ça sert à rien mais on est pas loin
En effet en dessous je vois :


Options -> Gestionnaire de package Nuget
Gestionaire de packages NuGet
Options -> Gestionnaire de package Nuget
Bon, tout ça ne sert à rien mais bon ... on va finir par y arriver.

Faire migrer packages.config vers PackageReference...

Tient qu'elle drôle cette possibilité, en cliquant droit sur le fichier package.config d'une ancienne solution Xamarin qu'elle n'est pas ma surprise :

Faire migrer packages.config vers PackageReference...
Je trouve cette possibilité dans une application dont les packages sont gérés par des fichiers package.config. Cette option apparait quand on clique droit sur le fichier.

Tient tient, j'essaye je clique :


Faire migrer packages.config vers PackageReference... Xamarin.Android
Je clique sur : M'aider à effectuer la migration vers PackageRefernce NuGet

Migrate from packages.config to PackageReference
Et là on m'explique les bénéfices et les limitation que j'ai à passer au PackageReference !? Exactement le contraire de ce que j'écrivais au début de ce post c'est à dire que les ingé de Redmond prennent à contre pied l'utilité des packages gérés dans le répertoire "packages" lié à une solution.

Managing the global packages, cache, and temp folders
Et là on me dit enfin tout sur cette nouvelle façon de gérer les NuGets Packages, franchement c'est du foutage de gueule non ?

Et pour finir on vous explique même comment revenir en arrière :

How to roll back to packages.config
On nous apprend que le processus de migration vers PackageReference à sauvé le fichier package.config qui vous permet de revenir en arrière.

Franchement que dire, que faire nous ne sommes que de petites choses, le principal est de trouver le bon chemin, le moins pénible pour arriver au bout du projet.


Références avant PackageReference
Une fois le passage à PackageReference effectué les nouvelles références se présentent ainsi :


Passage à PackageReference effectué
Voilà, encore une désagréable surprise avec la gestion des NuGets. Décidément on peut préférer la gestion façon GAC ou DLL d'antan. Il n'y a rien de facile rien de simple dans tout ça.

Have fun!

Développement d'applications avec Xamarin sous Visual Studio 2017

Je poursuis ma quête de développement d'applications multiplateformes avec Xamarin sous Visual Studio. Quand je vois les évolutions de ce Framework de développement, je plains ceux qui se sont lancé trop tôt tellement les choses ont changées et se sont stabilisées.

La fois précédente nous étions avec Windows 10 je prends mes travaux avec une machine de développement sous Windows 7 à priori pour l'instant pas de sous d'installation.

Prenons quelques notes de l'installeur :

Développement mobile en .NET iOS Android et Windows avec Xamarin
Développement mobile en .NET iOS Android et Windows avec Xamarin




C'est toujours bon de prendre des notes, ces choses changent tellement vite, on peut comparer avec la fois précédente.

Visual Studio 15.7.5

Fichiers -> Nouveau -> Projet :

New Project Xamarin Forms

Et on va créer une Cross-Platform Application mobile (Xamarin.Forms) comme précédemment seulement au moment de lancer l'application :




Pas d'emulateur d'Android
Pas d'emulateur d'Android
On est tout nu. Il faut réinstaller tout le bordel ...



Android Device Manager ...
Android Device Manager ...
Bon je reprends depuis mon article précédent et je réinstalle l'Android NDK. Je sais pas trop pourquoi.

Ca ne change rien par d'emulateur Android ....

J'exécute l'Android Device Manager puis bouton droit "Down system image" et ça continue nouvel installation ... c'est vraiment long.


Android Device Manager - Download System Image
Android Device Manager - Download System Image
Nougat 7.1 ça y ressemble cette c'est peut être bon ...
Il me faut quitter Visual Studio pour relancer :


Installation Android SDK
Installation Android SDK
Cette fois notre application Android peut démarrer dans l'émulateur :

Installation de L'Emulateur Android
Encore une ou deux bricoles :



Android Emulateur Recommended AVD
Android Emulateur Recommended AVD
Et oui, il ne fallait pas choisir ARM mais x86_64 ...

C'est reparti :

Android Download System Image
Android Download System Image
Mais cela ne suffit pas, vous l'avez compris on est revenu aux erreurs et aux affres de l'installation des émulateur Android et autres trucs qui ne fonctionnent pas du tout sous Windows 7 !

Pour vérifier, ouvrir le Android Device Manager et lancer l'emulateur par le bouton Start :



Xamarin pour Windows 7 ça ne fonctionne pas du tout !

On tombe dans les affres des différences qu'il y a entre Windows 7 et Windows 10.

MSDN Android Hardware Acceleration
Intel Hardware Accelerated Execution Manager

Installing using Android SDK Manager ...


Installation de HAXM par l'Android SDK Manager
Pu(bip) j'ai trouvé non sans mal :


Install Intel x86 Emulator Accelarator (HAXM installer)
Install Intel x86 Emulator Accelarator (HAXM installer)
Je relance Visual Studio, je relance mon application dans l'émulateur et devinez quoi ... Ca marche pas !!! Et bien non, il faut encore exécuter l'installeur de HAXM. Et où qu'il est l'installateur ?? Où qu'il est ?

Installateur de l'Intel HAXM

Il est là l'installateur :

C:\Program Files (x86)\Android\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager

Installateur HAXM d'Intel pour Android
Installateur HAXM d'Intel pour Android

Installateur HAXM d'Intel pour Android - Etape 1
Installateur HAXM d'Intel pour Android - Etape 2
A chaque fois, je quitte Visual et je le relance par précaution. Et cette fois vous croyez que ça va fonctionner ... suspense ...

Et bien NON !!!! ????? ERROR : Encryption unsuccessful



Install de HAXM d'Intel ne suffit pas !
Install de HAXM d'Intel ne suffit pas !
Perform a factory reset ! Et quoi encore, y'en a pas marre de tous ces trucs qui ne fonctionne pas !

Allé allons-y pour un petit factory reset vous vous souvenez où cela se trouve ? Voici :

Perform a factory reset sur l'Emulator Device
Du coup je lance mon émulateur à la main et ça y est enfin :


Exécution de l'Emulator Android après l'installation de l'Intel HAXM

Je vois la page d'accueil de l'OS Android sur l'émulateur.
Mais au lancement de l'application en exécution dans l'émulateur :



Visual Studio 2017 Xamarin et Windows 7 ça sens la mauvaise installation ...
Visual Studio 2017 Xamarin et Windows 7 ça sens la mauvaise installation ...
ERROR !

Gravité Code Description Projet Fichier Ligne État de la suppression
Erreur  Impossible de charger la tâche "Xamarin.Forms.Build.Tasks.GetTasksAbi" à partir de l'assembly D:\Users\Braby\.nuget\packages\xamarin.forms\3.0.0.561731\build\netstandard2.0\Xamarin.Forms.Build.Tasks.dll.
Impossible de charger le fichier ou l'assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' ou une de ses dépendances. Le fichier spécifié est introuvable. Assurez-vous que la déclaration <UsingTask> est correcte, que l'assembly et toutes ses dépendances sont disponibles et que la tâche contient une classe publique qui implémente Microsoft.Build.Framework.ITask. XamarinApp1.Android

Solution

Quand je vois tout ce qui est installé sur cette machine, je me dis que cela ne peut pas fonctionner, il faut nettoyer l'installation. Vous imaginez bien me je me suis battu avec ce truc, je suis passé par l'installation d'un outil pour Cleaner les versions du .NET Framework qui a finalement cassé les différentes versions.

Il y a avait deux problèmes sur ma machine :

1 - Mise à jour Windows Update - Echec

Une maj concernant une les différentes versions du .NET Framework n'avait pas pu s'effectuer, s'était déroulée avec une erreur :

2018-08 Correctif cumulatif de sécurité et de qualité .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1 et 4.7.2 pour Windows 7 et Server 2008 R2 pour systèmes x64 (KB4345590)
État de l'installation : Échec
Détails de l'erreur : Code 643

Casser les versions puis les réinstaller d'abord le 4.0 Client puis le 4.5 puis le 4.6 ... c'est l'outil dotnetfx_cleanup_tool qui m'a permis de faire tout cela.

2 - Mise à jour de Visual Studio 2017 avec l'installeur

Mise à jour de Visual Studio v15.5.1vers Visual Studio 15.18.1

Et c'est mis à fonctionner comme par miracle ... Voici ma première application XamarinForm1 sous Windows 7 :


Ma première application avec Xamarin - Windows 7 - Visual Studio 2017 15.8.1
Ma première application avec Xamarin - Windows 7 - Visual Studio 2017 15.8.1
C'est bientôt les vacances, oui moi je pars bientôt ... Je vous laisse n'hésitez pas laissez moi un petit commentaire ici ou sur un autre post.

Have fun !

Le cache de composants Visual Studio est obsolète - Redémarrez Visual Studio

Visual Studio erreur d'installation, le cache des composants est obsolète ? Que faire ? Alors que cela fonctionnait parfaitement ce matin je souhaite créer un nouveau projet Visual Studio. J'aimerais créer un "Nouveau Projet" ASP.NET Core, je choisie les options pour cela et là c'est le crache :


Le cache de composants Visual Studio est obsolète
Le cache de composants Visual Studio est obsolète
L'assembly Microsoft.VisualStudio.Web.MicrosoftAzure.AzureFunctions Version 15.0.0.0 est obsolète ...

Voyez-vous ça, c'est la catastrophe ! J'essaye de créer un autre type de projet Idem Visual Studio CRASH !

Je lis la littérature sur le sujet :.

Mettre à jour une installation réseau de Visual Studio

Résolution des problèmes d’installation et de mise à niveau de Visual Studio 2017

C'est quoi tout ce merdier ? Vous vous rendez compte si vous avez en plus à ce moment là vous avez un problème de Windows Update cela vous donne une sacrée envie de tout foutre à la poubelle et d'installer une distribution Linux Ubuntu ;-)

Pour ma part, je suis en train de tenter une Réparation de mon installation Visual Studio 2017 ... Dans l'installeur de Visual Studio 2017 j'ai cliqué sur Réparer :

Visual Studio Installer - Réparer
Visual Studio Installer - Réparer
Le processus de réparation se déroule :


Visual Studio 2017 15.7.5
Installer de Visual Studio 2017 15.7.5
Quand à la fin : Installation terminée avec des Avertissements ! En voilà encore une autre ...

Installer de Visual Studio 2017 15.7.5
Installer de Visual Studio 2017 15.7.5 - Avec des Avertissements !
Je clique sur Afficher les problèmes ...

Installer de Visual Studio 2017 15.7.5 Error Microsoft.NET.4.6.FullRedist.NonThreshold
Installer de Visual Studio 2017 15.7.5 Error Microsoft.NET.4.6.FullRedist.NonThreshold
Nous voilà bien ...

J'en étais sûr, depuis un moment déjà que je travaille avec Visual Studio 2017 Community, c'est à dire une version gratuite, je me disais que cela n'allait pas durer tout semblait fonctionner mais c'était trop beau pour être vrai.

Cela fait penser aux pires heures de Microsoft où il faisait perdre du temps volontairement aux gens qui n'achetait pas les modules de formation Microsoft Certified ... Si si vous vous rappelez ?

Not fun !!!

Vous pouvez cliquer sur les liens, il y des trucs en chinois ! Un lien c'est la résolution des problèmes que l'on a vu plus haut et le dernier lien pointe dans le journal :


dd_setup_20180730162653_004_Microsoft.Net.4.6.FullRedist.NonThreshold.log
dd_setup_20180730162653_004_Microsoft.Net.4.6.FullRedist.NonThreshold.log
Avec ça vais-je y arriver ?

... Oui je peux à nouveau créer un Projet ASP.NET Core :

My First Application ASP.NET Core
My First Application ASP.NET Core
Mais l'installation de la version 15.7.5 reste avec un avertissement ...

Et cette histoire de cache de composants obsolètes

Oui, souvenons nous, au tout début avant la réparation, il y a ce premier message ... En lançant l'installeur à nouveau et en me déplaçant dans l'onglet Emplacements d'installation, je vois une rubrique Cache de téléchargement et une case à cocher : Conserver le cache de téléchargement après l'installation.
Visual Studio Installeur
Visual Studio Installeur - Emplacements d'installation - Conserver le cache de téléchargement après l'installation
Peut être faudrait-il supprimer ce cache et recommencer une réparation ... j'ai pas le temps mais à voir.
Not fun !!! No At All !!!

NuGet comment faire autrement mais proprement avec gestion de configuration ?

NuGet vous trouvez toujours ça cool ? J'aurais bien quelques griefs à émettre. Alors je vais vous montrer ce que je fais pour m'en passer proprement. En même temps, on va travailler un peu avec Visual Studio 2015 Community et Team Services Cloud et voir ce que l'on peut faire avec tout cela.

NuGet quelques Griefs

Franchement Nuget, je ne trouve pas ça si cool que ça. Je trouve qu'ils sont un peu dépassés par leur succès. Quand je pense que les premières pages de pub sur NuGet disaient : "pour sortir enfin de l'enfer des DLLs" ou du GAC "Global Assembly Cache" et bien moi je trouve qu'on y est encore en plein et que NuGet vous oblige à migrer alors que parfois vous ne le souhaitez pas.

J'ai travaillé avec Prism sur les premières versions, j'ai archivé mon projet "using prism", je le ressort quelques années après, la version de Prism n'est plus gérée par le package correspondant au sein de NuGet. Je suis donc "obligé de migrer" c'est à dire de faire des modifications d'un code qui fonctionnait pour qu'il fonctionne à nouveau. Franchement je trouve pas ça cool ! Du moins c'est pas mieux qu'avant.

Comment se passer proprement de NuGet, créer un répertoire Assemblies

Rien de miraculeux mais une façon propre de créer quelque chose de pérenne et sans utiliser NuGet. Je créé un répertoire nommé : Assemblies à la racine de ma solution pour y placer les modules (les packages) que je souhaite sortir de la gestion de NuGet. Par exemple Log4Net.

Répertoire Assemblies des DLL en références dans mon projet non gérées par NuGet
La difficulté c'est de trouvé la DLL Log4Net seule sans NuGet autour. Je la trouve et je la place dans répertoire Assemblies et j'y fais référence dans mon projet et le tour est joué.

log4net est référencée dans mon projet

Mise en Gestion de Configuration de ma DLL

Comment retrouvé cette DLL log4net dans la gestion de configuration ? Ce qu'on remarque c'est que dans l'Explorateur de contrôle de code source c'est bien entendu vide :

La DLL n'est pas encore dans le contrôle de code source

Où sont les sources dans le Cloud de Team Services ?

On a vu que Visual Studio Online devenait Team Service mais comment y accéder depuis mon projet ouvert dans VS 2015 Community, moi j'ai trouvé le lien suivant :

Accès à Team Services depuis VS 2015 Community
On peut alors naviguer dans le projet sous Cloud :


Le répertoire Assemblies dans le gestionnaire de code sources est vide aussi :



Pour ajouter la DLL log4net dans le gestionnaire de configuration il faut "Ajouter les fichiers au contrôle de code source" de la façon suivante : Revenir dans Visual Studio dans l'Explorateur de solutions


Il faut encore un clique sur Ok :


Un petit + en vert vient s'ajouter devant le fichier dans l'Explorateur de solution, il faut encore archiver et actualiser pour voir ce fichier dans le gestionnaire de configuration de Team Services "cloud" :

DLL log4net maintenant en gestion de configuration
Voila c'est fait.

Conclusion

 Je vous l'avais dit, rien de miraculeux mais on est tranquille, le package Log4Net n'évolue plus (n'est plus en développement) il n'y a donc aucune raison de le suivre en gestion de configuration. Même s'il venait à être supprimer des NuGets Packages notre projet continuerait de fonctionner et c'était l'objectif.

Have fun !