Étrange problème avec le Système.Net.Http 4.2.0.0 pas trouvé
J'ai un étrange problème, ce qui me rend fou...
J'ai un simple Projet de Bibliothèque de classes (Plein .NET Framework, 4.6.1) avec une classe wrapper pour les fonctionnalités autour de Cosmos DB. Donc j'ai ajouté le “de Microsoft.Azure.DocumentDB” Package NuGet 1.19.1 à ce projet. Autre que cela, j'ai une référence à la “Newtonsoft.Json” Package NuGet 10.0.3, ainsi que d'un couple de "Microsoft.Diagnostics.EventFlow.*" Les Packages NuGet.
Jusqu'à présent, tout se compile sans erreur.
Mais dès que j'ai touché ma classe wrapper – utilisés à partir d'un simple Service de Tissu Apatrides (Service Complet .NET Framework 4.6.1) et essayez d'exécuter la ligne de code suivante:
_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);
- Je obtenir cette étrange erreur à l'exécution:
Système.IO.FileNotFoundException eu lieu HResult=0x80070002
Message=impossible de charger le fichier ou l'assembly 'Système.Net.Http,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ou
l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Source= StackTrace:
Microsoft.Azure.Documents.Client.DocumentClient.Initialiser(Uri
serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable1
1 desiredConsistencyLevel)
desiredConsistencyLevel) at
Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri
serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy
connectionPolicy, NullableIntérieure Exception 1: FileNotFoundException: impossible de charger le fichier ou l'
assemblage du Système.Net.Http, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' ou une de ses dépendances. L'
le système ne peut pas trouver le fichier spécifié.
Je n'ai absolument aucune idée, pourquoi le Système.Net.Http assemblée ne se trouve pas à tous – il y a même une référence d'assembly dans mon projet de bibliothèque de classes à la .Net Framework Assemblée “Du Système.Net.Http 4.0.0.0”.
Ce que je ne comprends pas c'est qu'il y est cette étrange redirection de liaison vers 4.2.0.0 – où est que l'on en venir?
Pour contourner ce problème, j'ai essayé d'ajouter le suivant rediriger vers l'application.config du Service de Tissu de Service (qui est la consommation de la bibliothèque de classe):
Mais toujours pas de différence, j'ai toujours l'erreur lors de l'exécution.
Personne ayant une idée? Toute personne ayant vu une telle question?
Merci et salutations,
OliverB
Salut, OliverB! Avez-vous trouvé une solution de contournement pour ce problème? Je suis juste en face à la même situation et c'est un cauchemar 🙁
OriginalL'auteur OliverB | 2017-11-30
Vous devez vous connecter pour publier un commentaire.
Le problème auquel vous faites face est liée à Visual Studio, en particulier en 2017, qui est livré avec
System.Net.Http v4.2.0.0
. Toutefois, l'adoption de la nouvelle voie par laquelle toutes les références devraient être effectués via NuGet, la dernière version deSystem.Net.Http
qui est 4.3.3 contient la version de la dll 4.1.1.2.Le problème est que VS au moment de la compilation et à l'exécution ainsi ignore votre référence et il essaie de faire référence à la DLL il connaît.
Comment résoudre le problème:
c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\
); si vous avez une version différente puis le chemin légèrement différent, pas beaucoup siErreurs d'exécution: ajouter un assembly de redirection de liaison
Si vous regardez en ligne sur google, vous trouverez quelques questions en suspens avec Microsoft à ce sujet, donc j'espère qu'ils vont résoudre ce problème dans l'avenir.
Espère que cette aide.
Mise à jour:
Lorsque vous cherchez à trouver certains des corrections permanentes de ce problème à travailler sur les agents de build, a remarqué que, si vous migrez vers le nouveau NuGet PackageReference modèle (en
.csproj
pas danspackages.config
) a tendance à mieux fonctionner. Voici un lien vers le guide sur la façon de faire cette mise à jour: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-referenceMerci beaucoup, été en train de devenir fou en essayant de résoudre ce depuis quelques heures!
Juste un heads-up que le problème peut être résolu en supprimant le bindingRedirects si vous travaillez avec .NET 4.7.2.
Même problème, aujourd'hui, lors de la mise à 4.7.2. Système.IO.La Compression et du Système.D'exécution ont également été touchés. Suppression de la liaison redirige résolu le problème.
Oui! Enfin!!! Comme par @Alternatex et JB ci-dessus, pour 4.7.2 supprimer la bindingRedirects et maintenant d'or. Quelle douleur pour chaque mise à jour de framework de trouver la dernière chanson et la danse de routine nécessaire pour le Système.Net.Http.
OriginalL'auteur Andrei U
La suppression de la liaison de redirection a fonctionné pour moi, vous pouvez essayer de l'enlever:
Retrait de la bindingRedirect résolu le problème pour moi. Les tests unitaires n'ont pas été en passant avec la même erreur que les OP et maintenant ils travaillent.
OriginalL'auteur Vivek Sharma
Un complément à la réponse de @AndreiU déjà donné et comment reproduire les erreurs d'exécution au niveau local.
J'ai eu l'erreur d'exécution ci-dessous lors du déploiement d'Azur, pas localement.
Quand j'ai commencé à regarder les assemblages j'ai pu voir que mon projet web et projet de service ciblée 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
The system cannot find the file specified.
.En regardant le chemin d'accès à la propriété, nous pouvons voir que le projet web cibles .Net Framework assemblée, et les objectifs en matière de service d'un assemblage à partir de Visual Studio 2017. Étant donné que le serveur n'a pas de Visual Studio 2017 installé, l'erreur d'exécution se produit.
Chemin Web:
Le chemin de Service:
Quelque chose d'aussi simple que la mise en
Copy Local
àtrue
peut résoudre le problème, mais pas dans tous les cas.Afin de reproduire l'erreur en local sur votre machine, il suffit de supprimer le besoin
System.Net.Http.dll
à partir de Visual Studio dossier spécifique. Cela vous donnera l'erreur d'exécution et probablement quelques erreurs de build. Après, ils sont fixés, tout devrait fonctionner, au moins il a fait pour moi.Si vous avez installé
System.Net.Http
viaNuGet
vérifier que l'assemblée est utilisée en regardant le.csproj
version.System.Net.Http 4.3.4
donne à l'assemblée suivante par exemple:Si vous utilisez un serveur de build comme Jenkins, TeamCity ou AppVeyor l'exécution manquant
.dll
pourrait exister. Dans ce cas, il pourrait ne pas aider à utiliser NuGet version de Système.Net.Http ou la suppression du manque.dll
localement. Pour résoudre cette erreur de regarder la version qui n'est pas trouvé et lePublicKeyToken
. Après cela, créer une liaison de redirection dansWeb.config
ouApp.config
en fonction de votre projet. Dans mon cas, je voudrais utiliser 4.0.0.0 à la place:Une bonne Github fil sur la question:
https://github.com/dotnet/corefx/issues/22781
OriginalL'auteur Ogglas
J'ai rencontré cette erreur quand j'ai déployé un service web pour l'un de nos serveurs. Le projet a pour cible .Net framework 4.7.2, ce qui n'était pas installé sur le serveur. L'installation de la 4.7.2-cadre sur le serveur corrigé le problème.
OriginalL'auteur Mark
Ce que j'ai fait pour résoudre le problème a été supprimé toutes les liaisons depuis le web.config et a fait un
Update-Package -reinstall
Cette supprimé un tas de vieux liaisons qui n'ont probablement pas besoin d'être là et fait un bon nettoyage.
OriginalL'auteur Jamie R Rytlewski
J'ai eu le même problème. En fin de compte je l'ai résolu en changeant le déploiement FabricApplication.ps1 à quelque chose comme ceci
J'ai trouvé un 4.2.0.0 System.Net.Http.dll c'est x64. Avant le déploiement de ce script copie de la dll dans le répertoire du package et les modifications du fichier de configuration à utiliser explicitement ce fichier. J'ai aussi écrit un blog à propos de mon Système.Net.Http problèmes à http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html
Ne pas oublier de remplacer le [ProjectName] avec votre propre nom de projet
Espère que cette aide, n'hésitez pas à demander
OriginalL'auteur user8862383
Une solution simple que j'ai trouvé que la décote de la cible cadre de projet web à 4,6.
J'ai créer un client et d'applications web, client .net framework 4.7.1 et les web ayant la même et je suis confronté à la même question, quand je reviens de la cible .net framework pour le web, c'est le travail pour moi.
OriginalL'auteur Raquib
A été pour moi quelque chose de vraiment étrange. Besoin d'heures de débogage après avoir trouvé quel était le problème. Il ne s'est pas produit localement, mais uniquement lors de l'utilisation de jenkins pour construire le projet.
J'ai eu une petite bibliothèque à l'aide de dotnet standart 2.0 et le projet principal a été WCF projet, qui repose sur la normale .NET(le mien a été spécialement v4.6.1). Mais dans le démarrage de classe de la dotnet standart de la bibliothèque, j'ai eu un peu de code qui ressemble à ceci:
IStaticDataConfiguration interface se présente comme ci-dessous:
Cette interface réside à l'intérieur de la dotnet standart de la bibliothèque tandis que la mise en œuvre est en dehors d'elle(son situé dans WCF projet).
De l'extérieur de la bibliothèque, j'ai été l'appel de la
AddStaticDataConfiguration
méthode comme ci-dessous:Le problème est que je suis de passage d'un
Func<HttpClient>
normale .Un projet de réseau à un dotnet standart de la bibliothèque qui, pour certaines, fou raison dotnet standart ne l'aime pas, et peut-être qu'il penseHttpClient
est à venir à partir de différentes classes, comme un résultat de jeterSystem.Net.Http 4.x.x.x
pas trouvé exception. Au moment d'enlever le code pour ne pas accepter unHttpClient
normale .Un projet de réseau, mais la création d'un nouveaufunc
à l'intérieur de la bibliothèque elle-même ses heureux et fonctionne bien.Espérons que cela pourrait aider quelqu'un d'autre depuis cette erreur qui se passe pour de nombreuses raisons 🙂
OriginalL'auteur Rajmond Burgaj