Problème étrange avec System.Net.Http 4.2.0.0 introuvable

Question

J'ai un problème étrange qui me rend fou…

J'ai un projet de Bibliothèque de classes simple (Framework .NET complet, 4.6.1) avec une classe wrapper pour une fonctionnalité autour de Cosmos DB. J'ai donc ajouté le package NuGet "Microsoft.Azure.DocumentDB" 1.19.1 à ce projet. En plus de cela, j'ai une référence au package NuGet "Newtonsoft.Json" 10.0.3, ainsi qu'à quelques packages NuGet "Microsoft.Diagnostics.EventFlow.*".

Jusqu'ici, tout compile sans erreur.

Mais dès que j'atteins ma classe wrapper - consommée par un simple Service Fabric Stateless Service (Framework .NET complet 4.6.1) - et que j'essaie d'exécuter la ligne de code suivante :

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

Je reçois cette étrange erreur à l'exécution:

System.IO.FileNotFoundException est survenue HResult=0x80070002
Message=Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Source= StackTrace: at Microsoft.Azure.Documents.Client.DocumentClient.Initialize(Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 desiredConsistencyLevel)

Inner Exception 1: FileNotFoundException: Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ou une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

Je n'ai absolument aucune idée pourquoi l'assembly System.Net.Http n'est pas du tout trouvé - il y a même une référence à l'assembly dans mon projet de Bibliothèque de classes pour le Framework .Net "System.Net.Http 4.0.0.0".

Ce que je ne comprends pas non plus, c'est cette redirection étrange vers 4.2.0.0 - d'où vient-elle? Pour contourner cela, j'ai essayé d'ajouter la redirection suivante dans le app.config du Service Fabric Service (qui consomme la bibliothèque de classes):

Mais toujours pas de différence, j'obtiens toujours l'erreur à l'exécution.

Quelqu'un a une idée? Quelqu'un a déjà rencontré ce problème?

Answer 1

Le problème que vous rencontrez est lié à Visual Studio, en particulier 2017 qui est livré avec System.Net.Http v4.2.0.0. Cependant, en adoptant la nouvelle méthode où toutes les références doivent être faites via NuGet, la dernière version de System.Net.Http qui est 4.3.3 contient la version du fichier dll 4.1.1.2.

Le problème est que VS, au moment de la construction et au moment de l'exécution, ignorera votre référence et essaiera de référencer le DLL qu'il connaît.

Comment le résoudre :

• Assurez-vous que toutes les références à System.Net.Http sont faites via NuGet

• Erreurs au moment de la construction : changez l'extension de System.Net.Http.dll (ou déplacez-le ailleurs... en gros, supprimez-le) qui est livré avec VS 2017 (c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); si vous avez une version différente, le chemin sera légèrement différent, mais pas beaucoup

• Erreurs au moment de l'exécution : ajoutez une redirection d'assemblage

Si vous cherchez en ligne sur Google, vous trouverez quelques problèmes ouverts avec Microsoft à ce sujet, donc j'espère qu'ils corrigeront cela à l'avenir.

Mise à jour :

En cherchant des solutions permanentes pour ce problème sur les agents de construction, j'ai remarqué que si vous migrez vers le nouveau modèle NuGet PackageReference (dans .csproj et non dans packages.config), cela a tendance à mieux fonctionner. Voici un lien vers le guide sur comment procéder à cette mise à jour : https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

Answer 2

Supprimer la redirection de liaison a fonctionné pour moi, vous pouvez essayer de la supprimer :

Answer 3

Un ajout à la réponse que @AndreiU a déjà donnée et comment reproduire les erreurs d'exécution localement.

J'ai obtenu l'erreur d'exécution ci-dessous lors du déploiement sur Azure, pas localement.

{"Message":"Une erreur est survenue.","ExceptionMessage":"Une erreur s'est produite lors de la tentative de création d'un contrôleur de type 'OrderController'. Assurez-vous que le contrôleur a un constructeur public sans paramètres.","ExceptionType":"System.InvalidOperationException","StackTrace":" à System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)\r\n at System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(HttpRequestMessage request)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()","InnerException":{"Message":"Une erreur est survenue.","ExceptionMessage":"Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ou l'un de ses dépendances. Le système ne peut pas trouver le fichier spécifié.","ExceptionType":"System.IO.FileNotFoundException","StackTrace":" chez Company.Project.Service.CompanyIntegrationApiService..ctor(Uri baseAddress)\r\n at Company.Project.BackOffice.Web.Controllers.OrderController..ctor() in C:\projects\company-project\src\Company.Project.BackOffice.Web\Controllers\Order\OrderController.cs:ligne 30\r\n chez lambda_method(Fermeture )\r\n chez System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)"}}

Lorsque j'ai commencé à regarder les assemblies, j'ai pu voir que mon projet Web et mon projet de service ciblaient des versions différentes pour System.Net.Http.

Projet Web :

Projet de service :

Il est facile de penser que cela est causé par une incompatibilité de versions, mais la clé ici est de regarder l'erreur Le système ne peut pas trouver le fichier spécifié..

En regardant la propriété du chemin, nous pouvons voir que le projet Web cible un assembly .Net Framework tandis que le service cible un assembly de Visual Studio 2017. Comme le serveur n'a pas installé Visual Studio 2017, l'erreur d'exécution se produira.

Chemin Web :

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

Chemin du service :

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

Quelque chose d'aussi simple que définir Copy Local sur true peut résoudre le problème, cependant pas dans tous les cas.

Pour reproduire l'erreur sur votre machine locale, il suffit de supprimer le System.Net.Http.dll nécessaire du dossier spécifique à Visual Studio. Cela vous donnera l'erreur d'exécution et probablement des erreurs de build. Après les avoir corrigés, tout devrait fonctionner, du moins c'est ce qui s'est passé pour moi.

Si vous avez installé System.Net.Http via NuGet, vérifiez quel assembly est utilisé en regardant la version du fichier .csproj. System.Net.Http 4.3.4 donne par exemple l'assembly suivant :

  ..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll
  True

Si vous utilisez un serveur de build comme Jenkins, TeamCity ou AppVeyor, le .dll manquant à l'exécution peut également s'y trouver. Dans ce cas, cela peut ne pas aider d'utiliser la version NuGet de System.Net.Http ou de supprimer localement le .dll manquant. Pour résoudre cette erreur, regardez la version qui n'est pas trouvée et le PublicKeyToken spécifique. Ensuite, créez une redirection de liaison dans Web.config ou App.config selon votre projet. Dans mon cas, je voudrais utiliser 4.0.0.0 à la place :

Un bon fil de discussion Github sur le problème :

https://github.com/dotnet/corefx/issues/22781

Answer 4

Ce que j'ai fait pour résoudre le problème a été de supprimer toutes les liaisons du fichier web.config et de faire un

Mise à jour de l'emballage -réinstallation

Cela a supprimé un tas d'anciennes liaisons qui ne sont probablement pas nécessaires et a effectué en fait un bon nettoyage.

Answer 5

J'ai rencontré cette erreur lorsque j'ai déployé un service web sur l'un de nos serveurs. Le projet était basé sur le framework .Net 4.7.2, qui n'était pas installé sur le serveur. L'installation du framework 4.7.2 sur le serveur a corrigé le problème.