L’ajout de bibliothèques .NET Standard à la bibliothèque 4.7.1 ajoute des charges de références, dont certaines cassées
Comme je dois importer une bibliothèque ciblant .NET Standard 2, j'avais mis à niveau ma bibliothèque vers .NET 4.7.1, comme je l'ai compris grâce à cette vidéo MS qui devrait éviter ce problème: https://www.youtube.com/ regarder? v = u67Eu_IgEMs
Cependant, l'ajout de la norme .NET entraîne désormais des dizaines de références System.xxx, plutôt qu'une seule référence à la norme .NET (comme dans la vidéo).
Pire encore, plusieurs références ont été ajoutées, mais le fichier sous-jacent semble manquer, ce qui génère des avertissements, par exemple
Warning The referenced component 'Microsoft.Win32.Primitives' could not be found.
Warning The referenced component 'System.IO.FileSystem' could not be found.
Warning The referenced component 'System.Security.Cryptography.X509Certificates' could not be found.
Warning The referenced component 'System.Globalization.Calendars' could not be found. J'ai même recréé le projet de démonstration en vidéo et obtenu le même résultat - aucune référence unique. NET Standard, beaucoup de références DLL à la place.
Warning The referenced component 'System.Security.Cryptography.Encoding' could not be found.
Warning The referenced component 'System.Security.Cryptography.Primitives' could not be found.
Warning The referenced component 'System.IO.Compression.ZipFile' could not be found.
Warning The referenced component 'System.Console' could not be found.
J'ai également essayé un update-package -reinstall NUGET, ainsi que la mise à niveau et la mise à niveau vers .NET Standard 2.0 et 2.0.1.
La réponse que je crée pour ma propre question est la suivante:
Votre projet .NET Framework utilise-t-il packages.config? Si tel est le cas, NE PAS faire référence à des bibliothèques .NET Standard. Le paquet/référence/liaison-redirection dans VS 2017 est horriblement cassé si vous introduisez .NET Standard. Essayer de le réparer causera plus de problèmes (j'ai perdu plusieurs jours à essayer). Attendez-vous à des assemblages qui ne se chargent pas malgré leur présence, à de nombreux avertissements et à une application défectueuse.
Si vous utilisez System.Net.Http, prévoyez de passer plusieurs jours à résoudre les problèmes liés à Google et à GitHub.
Si vous pouvez mettre à niveau vers packageReferences, cela devrait résoudre le problème. Toutefois, si votre projet contient des packages qui importent du contenu, tels que JQuery ou Bootstrap, sachez que ceux-ci ne fonctionnent plus et que vous passerez plus de temps à essayer de corriger ces références et à migrer vers npm ou bower, ainsi que pour corriger la compilation TypeScript. Non merci.
Dans l'idéal, vous utiliseriez le format csproj 2017, mais ce n'est pas compatible avec WinForms, ASP.NET ou Windows Services - si difficile si vous avez un projet hérité.
En raison de problèmes liés à la mise en œuvre du support .NET Standard 2.0 sur .NET Framework 4.7.1, des fichiers supplémentaires doivent être déployés dans votre dossier bin.
Ce problème est décrit comme un problème connu ici .
Le nombre de fichiers copiés dans le dossier de sortie sera égal à 0 lorsque vous ciblerez ou exécuterez sur .NET Framework 4.7.2.
Assurez-vous également que vous utilisez la dernière version de Visual Studio (au moins la version 15.6.3), car certaines des modifications requises pour que ce scénario fonctionne bien sont disponibles ici.
FWIW, j'utilisais Visual Studio 15.7.5 et corrigeais manuellement toutes mes redirections de liaison (pour les supprimer). Cependant, j'ai remarqué que Visual Studio 15.9.4 était installé dans mon collègue et que, dans l'écran des propriétés du projet, il y a maintenant un "Génération automatique des redirections de liaison". Je l'avais précédemment défini dans le csproj manuellement. Cependant, la mise à jour vers VS 15.9.4 et la reconstruction des projets ont éliminé toutes les redirections de liaison pour moi.
J'ai eu absolument le même problème. J'essayais d'installer le package Microsoft.Azure.ServiceBus sur le projet de console vide .NET Framework 4.7.1 et j'ai obtenu toutes ces références cassées.
D'après ce que j'ai compris, la cause fondamentale est https://github.com/dotnet/standard/issues/567 et la solution de contournement possible décrite ici https://github.com/dotnet/corefx/issues/ 29622 # issuecomment-396753264
Je viens donc de remplacer les références brisées comme
<Reference Include="System.Security.Cryptography.Primitives, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Security.Cryptography.Primitives.4.3.0\lib\net46\System.Security.Cryptography.Primitives.dll</HintPath>
</Reference>
dans mon fichier .csproj à
<Reference Include="System.Security.Cryptography.Primitives"/>
et cela avait fonctionné parce que cette Assemblée est la partie de .NET Framework 4.7.1. De plus, j'ai supprimé toutes les redirections de liaison du fichier .config concernant les références cassées.
De plus, j'ai trouvé un fait intéressant. Il y avait une référence
<Reference Include="System.Runtime.Serialization.Primitives, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Runtime.Serialization.Primitives.4.3.0\lib\net46\System.Runtime.Serialization.Primitives.dll</HintPath>
</Reference>
et il n'a pas été cassé, car cet assembly existe dans le dossier .../MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib. Je me demande donc si cela pourrait être le problème de la compilation de MS.