web-dev-qa-db-fra.com

Impossible de charger le fichier ou l'assembly "System.Net.Http, version = 4.0.0.0, Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a"

J'ai copié mon projet sur un ordinateur Windows 10 propre avec uniquement Visual Studio 2015 Community et SQL Server 2016 Express installé. Aucune autre version de structure n'est installée à part celles installées avec Windows 10 et VS2015 ou SQL Server.

Lorsque j'essaie de démarrer le projet WebApi, je reçois le message suivant:

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é.

Les forfaits du projet comprennent:

<package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Tracing" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.3" targetFramework="net45" />

Après avoir créé le projet avec .NET Framework 4.6.1, System.Net.Http, le fichier ne se trouve pas dans le dossier bin.

Le chemin du fichier pointe vers:

C:\Program Files (x86)\Assemblys de référence\Microsoft\Framework.NETFramework\v4.6.1\System.Net.Http.dll

Le chemin du fichier de System.Net.Http.Formatting pointe vers:

C:\Development\MyApp\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll

L’ensemble du projet doit-il viser 4.5.1 ou existe-t-il un autre moyen de référencer les bons assemblages?

c#visual-studio-2015
88
Ivan-Mark Debono

Changer les informations de liaison dans mon web.config (ou app.config) - tout en étant un "hack" à mon avis, vous permet de faire avancer votre projet après la mise à jour d'un paquet NuGet endommageant votre application et vous donnant le System.Net.Http Erreur.

Définir newVersion = "4.0.0.0"

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

Suivez les étapes suivantes,

  1. Mettez Visual Studio à jour avec la dernière version (ça compte)
  2. Supprimer toutes les redirections de liaison de web.config

  3. Ajoutez ceci au fichier.csproj:

    <PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
  4. Construire le projet
  5. Dans le dossier bin, il devrait y avoir un fichier (WebAppName).dll.config
  6. Il devrait contenir des redirections, copiez-les dans le web.config
  7. Supprimez ce qui a été extrait du fichier.csproj

Ça devrait marcher

40
Sajeetharan

Dans l'un de mes projets, il y avait un paquet de nuget avec une version supérieure de System.Net.Http. et dans mon projet de démarrage il référence à System.Net.Http v 4.0.0, je viens d'installer paquet de nuget System.Net.Http dans mon projet de démarrage et le problème résolu

21
Ram

Si vous avez plusieurs projets dans votre solution, cliquez avec le bouton droit de la souris sur l'icône de la solution dans Visual Studio et sélectionnez "Gérer les packages NuGet pour la solution", puis cliquez sur le quatrième onglet "Consolidation" pour consolider tous vos projets dans la même version du logiciel. DLL. Cela vous donnera une liste des assemblys référencés à consolider. Cliquez sur chaque élément de la liste, puis cliquez sur Installer dans l'onglet qui apparaît à droite.

7
TruthSeeker

La bind-redirect ci-dessus ne fonctionnait pas pour moi, alors j'ai commenté la référence à System.Net.Http dans web.config. Tout semble fonctionner correctement sans cela.

  <system.web>
    <compilation debug="true" targetFramework="4.7.2">
      <assemblies>
        <!--<add Assembly="System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />-->
        <add Assembly="System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
      </assemblies>
    </compilation>
    <customErrors mode="Off" />
    <httpRuntime targetFramework="4.7.2" />
  </system.web>
4
Mark

J'ai le même problème et le seul moyen de résoudre ce problème est d'ajouter bindingRedirect à app.confing comment @ tripletdad99 a été écrit.

Mais si vous avez une solution avec plus de projet, c'est vraiment sucer mettre à jour chaque projet à la main (et parfois aussi après avoir mis à jour un paquet de nuget, vous devez le refaire). Et c’est la raison pour laquelle j’ai écrit un script PowerShell simple qui correspond à tous les app.configs.

 param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing app.config in $sourceDirectory"
Write-Host "$Package set oldVersion to $OldVersion and newVersion $NewVersion"
Write-Host "Search app.config files.."
[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
            Write-Host "Fix"
        }
    }
    $xml.Save($file)
}

Write-Host "Done"

Exemple d'utilisation:

./scripts/FixAppConfig.ps1 -SourceDirectory "C:\project-folder" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.2.0" -NewVersion "4.0.0.0"

Ce n'est probablement pas parfait et ce sera mieux si quelqu'un le lie à la tâche de pré-construction.

4
Jiri Sykora

Changer suivant:

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

avec ce qui suit:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.0.0.0" />

dans web.config

2
Muhammad Waqas

Vous pouvez résoudre ce problème en mettant à niveau votre projet vers .NET Framework 4.7.2. Ceci a été a répondu Alex Ghiondea - MSFT . S'il vous plait, allez le consulter car il le mérite vraiment!

Ceci est documenté en tant que problème connu dans .NET Framework 4.7.1.

Pour résoudre ce problème, vous pouvez ajouter ces cibles à votre projet. Ils vont Supprimez DesignFacadesToFilter de la liste des références transmises à SGEN (et les rajouter une fois que SGEN est terminé)

<Target Name="RemoveDesignTimeFacadesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <DesignFacadesToFilter Include="System.IO.Compression.ZipFile" />
    <_FilterOutFromReferencePath Include="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" 
        Condition="'@(DesignFacadesToFilter)' == '@(_DesignTimeFacadeAssemblies_Names)' and '%(Identity)' != ''" /> 
    <ReferencePath Remove="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Removing DesignTimeFacades from ReferencePath before running SGen." /> </Target>

<Target Name="ReAddDesignTimeFacadesBeforeSGen" AfterTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <ReferencePath Include="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Adding back DesignTimeFacades from ReferencePath now that SGen has ran." />
</Target> Edit: If the above doesn't work, please share a detailed msbuild log to help understand why the target doesn't work.

Une autre option (à l'échelle de la machine) consiste à ajouter la redirection de liaison suivante à sgen.exe.config:

<runtime>
  <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.IO.Compression.ZipFile" publicKeyToken="b77a5c561934e089" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime> This will only work on machines with .NET Framework 4.7.1. installed. Once .NET Framework 4.7.2 is installed on that machine, this workaround should be removed.
2
Boško Bezik

Cela fonctionnera dans .NET 4.7.2 avec Visual Studio 2017 (15.9.4): 

  • Supprimer les redirections de liaison web/app.config
  • Supprimer le package NuGet pour System.Net.Http
  • Ouvrez "Ajouter une nouvelle référence" et créez un lien direct vers la nouvelle version 4.2.0.0 fournie avec .NET 4.7.2

 ![image](https://user-images.githubusercontent.com/38843378/50998531-b5bb3a00-14f5-11e9-92df-6c590c469349.png)

1
EnocNRoll - Ananda Gopal

J'avais ceci, mais c'était parce que j'avais ajouté un paquet NuGet qui avait mis à jour les redirections de liaison. Une fois que j'ai supprimé le paquet, les redirections étaient toujours là. Je les ai tous supprimés, puis j'ai lancé update-package -reinstall. Cela a ajouté les redirections correctes.

1
SwampyFox

Pour moi, la seule façon de résoudre ce problème (.NET 4.6.1) consistait non seulement à ajouter une référence Nuget à System.Net.Http V4.3.4 pour le projet qui utilisait réellement System.Net.Http, mais également à la projet de démarrage (un projet de test dans mon cas).

(Ce qui est étrange, car le fichier System.Net.Http.dll correct existait dans le répertoire bin du projet test et les images .config assemblyBingings semblaient également correctes.)

0
TvdH

Vérifiez la version du framework .net.
Mon framework .net original est une version plus ancienne.
Après avoir installé .net framework 4.6, ce problème est automatiquement résolu.

0
Frank Myat Thu

Pour moi, j'avais configuré mon projet pour qu'il s'exécute sur la dernière version de .Net Framework (changement de .Net Framework 4.6.1 à 4.7.2).

Tout a fonctionné, aucune erreur et publié sans problème, et ce n'est que par hasard que je suis tombé sur le message d'erreur System.Net.Http, présenté dans une petite requête API difficile à remarquer, mais assez importante, sur le site Web I ' m travaille sur.

Je suis revenu à 4.6.1 et tout va bien à nouveau.

0
Stuart Aitken