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

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

J'ai un projet de bibliothèque de classes simple (Full .NET Framework, 4.6.1) avec une classe wrapper pour les fonctionnalités autour de Cosmos DB. Par conséquent, j'ai ajouté le package NuGet 1.19.1 «Microsoft.Azure.DocumentDB» à ce projet. Autre que cela, j'ai une référence au package NuGet «Newtonsoft.Json» 10.0.3, ainsi qu'à quelques packages NuGet «Microsoft.Diagnostics.EventFlow. *».

Jusqu'à présent, tout se compile sans aucune erreur.

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

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

J'obtiens cette étrange erreur au moment de l'exécution:

System.IO.FileNotFoundException s'est produite HResult = 0x80070002
Message = Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutre, 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.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 désiréConsistencyLevel)

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

Je n'ai absolument aucune idée de la raison pour laquelle l'assembly System.Net.Http n'est pas du tout trouvé - il y a même une référence d'assembly dans mon projet de bibliothèque de classes à l'assembly .Net Framework «System.Net.Http 4.0.0.0».

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

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

Quelqu'un a un indice? Quelqu'un ayant vu un tel problème?

Merci et salutations, OliverB

Le problème auquel vous êtes confronté est lié à Visual Studio, en particulier à 2017 qui est livré avec System.Net.Http v4.2.0.0. Cependant, en adoptant la nouvelle manière selon laquelle toutes les références doivent être faites via NuGet, la dernière version System.Net.Httpest 4.3.3 contient la version 4.1.1.2 de la dll.

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 la DLL qu'il connaît.

Comment le réparer:

• assurez-vous que toutes les références à System.Net.Http sont effectuées via NuGet
• Erreurs de temps de construction: changez l'extension de System.Net.Http.dll (ou déplacez-la ailleurs ... en gros, débarrassez-vous-en) qui est livrée 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 d'exécution: ajouter une redirection de liaison d'assembly

Si vous regardez en ligne sur google, vous trouverez quelques problèmes ouverts avec Microsoft à ce sujet, alors j'espère qu'ils résoudront ce problème à l'avenir.

J'espère que cela t'aides.

Mettre à jour:

Lorsque vous cherchez à trouver des correctifs permanents pour que ce problème fonctionne sur les agents de build, vous avez remarqué que si vous migrez vers le nouveau modèle NuGet PackageReference (in .csprojnot in packages.config) a tendance à mieux fonctionner. Voici un lien vers le guide sur la façon de faire cette mise à niveau: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

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

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

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

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

Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou l'une de ses dépendances. Le système ne trouve pas le fichier spécifié. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" à Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n à Company.Project .BackOffice.Web.Controllers.OrderController..ctor () dans C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: ligne 30 \ r \ n à lambda_method ( Closure) \ r \ n à System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (requête HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, tapez controllerType) "}} Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a 'ou l'une de ses dépendances. Le système ne trouve pas le fichier spécifié. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" à Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n à Company.Project .BackOffice.Web.Controllers.OrderController..ctor () dans C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: ligne 30 \ r \ n à lambda_method ( Closure) \ r \ n à System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (requête HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, tapez controllerType) "}} Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a 'ou l'une de ses dépendances. Le système ne trouve pas le fichier spécifié. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" à Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n à Company.Project .BackOffice.Web.Controllers.OrderController..ctor () dans C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: ligne 30 \ r \ n à lambda_method ( Closure) \ r \ n à System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (requête HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, tapez controllerType) "}}

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

Projet Web:

Projet de service:

Il est facile de penser que cela est dû à une incohérence dans les versions, mais la clé ici est de regarder l'erreur The system cannot find the file specified..

En examinant la propriété path, nous pouvons voir que le projet Web cible un assembly .Net Framework tandis que le service cible un assembly de Visual Studio 2017. Étant donné que Visual Studio 2017 n'est pas installé sur le serveur, l'erreur d'exécution se produit.

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 Copy Localde truerégler le problème peut résoudre le problème, mais pas dans tous les cas.

Afin de reproduire l'erreur sur votre ordinateur local, supprimez simplement le nécessaire System.Net.Http.dlldu dossier spécifique à Visual Studio. Cela vous donnera l'erreur d'exécution et probablement quelques erreurs de construction. Une fois ceux-ci résolus, tout devrait fonctionner, du moins pour moi.

Si vous avez installé System.Net.Httpvia, NuGetvérifiez quel assemblage est utilisé en regardant la .csprojversion. System.Net.Http 4.3.4donne par exemple l'assemblage suivant:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Si vous utilisez un serveur de build comme Jenkins, TeamCity ou AppVeyor, le runtime manquant .dllpeut également y exister. Dans ce cas, il peut ne pas être utile d'utiliser la version NuGet de System.Net.Http ou de supprimer les fichiers manquants .dlllocalement. Pour résoudre cette erreur, regardez la version qui n'est pas trouvée et le spécifique PublicKeyToken. Après cela, créez une redirection de liaison dans Web.configou en App.configfonction de votre projet. Dans mon cas, je voudrais utiliser 4.0.0.0 à la place:

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>

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

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

Je viens de l'installer en System.Net.Httputilisant NuGet. Tu peux l'attraper ici:

https://www.nuget.org/packages/System.Net.Http/

Le ASP.NET MVCprojet sur lequel je travaille sur des cibles .NET 4.6.1. Cela fonctionne parfaitement sur ma machine lors du débogage dansIIS Express avec Visual Studio 2019.

Le problème s'est produit lors de la tentative d'exécution de l'application déployée sur Azure. J'obtenais cette erreur:

Impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou l'une de ses dépendances.

Ce qui a vraiment fonctionné dans mon cas, c'est d'ouvrir le fichier .csproj et de rechercher System.Net.Httpcomme dans la capture d'écran suivante ...

Vérifiez que le .csprojfichier a la version 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

Le <HintPath>indique en fait le..\packages dossier de Nuget, c'est-à-dire qu'il s'agit de la version réelle installée par Nuget. Une fois déployée, cette version spécifique sera également restaurée côté serveur et tout devrait fonctionner avec une redirection de liaison.

... et donc la redirection de liaison doit mentionner cette version spécifique Web.configcomme ceci:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.3" />
</dependentAssembly>

Cela a résolu le problème dans mon cas après quelques validations sur Azure Kudu . Le site Web Azure a finalement démarré sans erreur.

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

Update-Package -reinstall

Cela a supprimé un tas d'anciennes fixations qui n'avaient probablement pas besoin d'être là et ont fait un bon nettoyage.

J'ai rencontré cette erreur lorsque j'ai déployé un service Web sur l'un de nos serveurs. Le projet ciblait .Net Framework 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.

La réponse d'Andrei U a conduit à mon salut. Cependant, le raisonnement ne correspondait pas à mon cas. Pour les personnes qui sont dans le même scénario que moi:

C'était une erreur d'exécution (pas au moment de la construction), où la construction a réussi, mais fonctionnait sur un ordinateur, mais pas sur le serveur. Solution: - Ajout du package System.Net.Http. - Renommer le fichier: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (par exemple renommer en: System.Net.Http.dll.BAK) sur le serveur de construction.

Je n'avais pas et je n'ai toujours pas de redirections d'assembly pour cette dll

J'ai trouvé une solution simple qui rétrograde le cadre cible du projet Web à 4.6.

Je crée un client et une application Web, le client ayant le framework .net 4.7.1 et le Web ayant le même problème et je suis confronté au même problème, lorsque je rétrograde le framework .net cible pour le Web, cela fonctionne pour moi.

Après avoir lutté avec cela pendant quelques jours, j'ai finalement résolu le problème .Net 4.7.2 / System.Net.Http pour mon projet. En plus de changer le fichier * .csproj pour cibler la version 4.7.2 du framework, j'ai dû également mettre à jour app.config dans les projets à partir de

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

à:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

J'ai eu le même problème. En fin de compte, je l'ai résolu en changeant le Deploy-FabricApplication.ps1 en quelque chose comme ça

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

J'ai trouvé un System.Net.Http.dll 4.2.0.0 qui est x64. Avant de déployer ce script copie la dll dans le répertoire du package et modifie le fichier de configuration pour utiliser explicitement ce fichier. J'ai également écrit un blog sur mes problèmes System.Net.Http à http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

N'oubliez pas de remplacer [ProjectName] par votre propre nom de projet

J'espère que cela aide, n'hésitez pas à demander

Pour moi, c'était quelque chose de vraiment étrange. Besoin d'heures de débogage après avoir trouvé quel était le problème. Cela ne s'est pas produit localement mais uniquement lors de l'utilisation de jenkins pour construire le projet.

J'avais une petite bibliothèque utilisant dotnet standart 2.0 et le projet principal était un projet WCF basé sur .NET normal (le mien était spécifiquement v4.6.1). Mais dans la classe de démarrage de la bibliothèque standart dotnet, j'avais un code qui ressemblait à ceci:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

L'interface IStaticDataConfiguration ressemble à ci-dessous:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

Cette interface réside à l'intérieur de la bibliothèque standart dotnet tandis que l'implémentation est à l'extérieur de celle-ci (elle est située dans le projet WCF).

De l'extérieur de la bibliothèque, j'appelais le AddStaticDataConfiguration méthode comme ci-dessous:

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

Le problème est que je passe un Func<HttpClient>projet .NET normal à une bibliothèque dotnet standart qui, pour une raison folle, dotnet standart n'aime pas et pense peut-être HttpClientprovenir de différentes classes, ce qui entraîne une System.Net.Http 4.x.x.xexception non trouvée. Une fois supprimé, le code pour ne pas accepter un HttpClientprojet .NET normal, mais créer un nouveau funcà l'intérieur de la bibliothèque elle-même, c'est heureux et fonctionne bien. J'espère que cela pourrait aider quelqu'un d'autre car cette erreur se produit pour de nombreuses raisons :)

Ma solution était similaire à celle de @ Raquib. Mon projet était 4.7.2 et fonctionnait très bien sur mon PC. Chaque fois que je déployais sur notre serveur de développement, le problème était mentionné dans la question. Il s'avère que la version .net la plus élevée sur le serveur était la version 4.6.1. La rétrogradation de mon projet vers la version 4.6.1 a résolu le problème. La mise à niveau de la version .net du serveur n'était pas une option pour moi.

Je pense qu'une partie de la réponse peut être trouvée dans la documentation de Microsoft .

Lorsque vous créez une application de bureau dans Visual Studio qui cible le .NET Framework 4.5.1 ou une version ultérieure, l'application utilise la redirection de liaison automatique.

Comme le souligne la réponse de @Vivek Sharma, supprimer:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

résolu le problème dans 3 cas de ce type dans mon application. Lorsque vous examinez la DLL avec Powershell, par exemple:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

Les sorties

System.Net.Sockets, version = 4.0.0.0

Il est clair qu'une redirection de liaison vers 4.2.0.0ne fonctionnera pas car nous sortons 4.0.0.0dans la corbeille.

Il vaut également la peine de vérifier le GAC pour voir si l'assemblage est également absent de là:

 gacutil -l System.Net.Sockets

Dans mon cas, la version particulière était également absente du GAC. Si la DLL était dans le GAC, elle aurait dû être trouvée dans le processus de liaison d'assembly .

Supprimez d'abord de votre système de fichiers local:

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

Supprimez ensuite toutes les références dans Projets et ajoutez une référence 4.0.
Cela m'a résolu mon problème.