c# - studio - No se pudo cargar el archivo o ensamblado "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

visual studio express 2015 descargar

Question

Copié mi proyecto en una máquina limpia de Windows 10 con solo Visual Studio 2015 Community y SQL Server 2016 Express instalados. No hay otras versiones de framework instaladas aparte de las instaladas con Windows 10 y VS2015 o SQL Server.

Cuando intento iniciar el proyecto WebApi, recibo el mensaje:

No se pudo cargar el archivo o ensamblado "System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" o una de sus dependencias. El sistema no puede encontrar el archivo especificado.

Los paquetes del proyecto incluyen:

<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" />

Después de compilar el proyecto con .NET Framework 4.6.1, System.Net.Http , el archivo no se encuentra en la carpeta bin .

La ruta del archivo apunta a:

C: / Archivos de programa (x86) / Ensamblados de referencia / Microsoft / Framework.NETFramework / v4.6.1 / System.Net.Http.dll

La ruta del archivo de System.Net.Http.Formatting apunta a:

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

¿Debería todo el proyecto apuntar a 4.5.1 o hay otra forma de hacer referencia a los ensamblajes correctos?

Answer 1

Cambiar la información de enlace en mi web.config (o app.config), aunque es un "hack" en mi opinión, le permite avanzar con su proyecto después de que una actualización del paquete NuGet golpee su aplicación y le proporcione el System.Net.Http error.

Establecer 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>

Answer 2

Cambiar siguiente:

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

con lo siguiente:

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

en web.config

Answer 3

El bind-redirect anterior no funcionó para mí, así que comenté la referencia a System.Net.Http en web.config . Todo parece funcionar bien sin él.

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

Answer 4

En uno de mis proyectos había un paquete nuget con una versión superior de System.Net.Http. y en mi proyecto de inicio hay referencia a System.Net.Http v 4.0.0, acabo de instalar el paquete Nuget System.Net.Http en mi proyecto de inicio y el problema se resolvió

Answer 5

Esto funcionará en .NET 4.7.2 con Visual Studio 2017 (15.9.4):

• Eliminar las redirecciones de enlace web / app.config
• Eliminar el paquete NuGet para System.Net.Http
• Abra "Agregar nueva referencia" y enlace directamente a la nueva compilación 4.2.0.0 que se incluye con .NET 4.7.2

Answer 6

La única forma en que resolvió este problema limpiamente (.NET 4.6.1) fue no solo agregar una referencia de Nuget a System.Net.Http V4.3.4 para el proyecto que realmente usaba System.Net.Http, sino también proyecto de inicio (un proyecto de prueba en mi caso).

(Lo cual es extraño, porque el System.Net.Http.dll correcto existía en el directorio bin del proyecto de prueba y los .config assemblyBingings también se veían bien).

Answer 7

Para mí, había configurado mi proyecto para ejecutarse en la última versión de .Net Framework (un cambio de .Net Framework 4.6.1 a 4.7.2).

Todo funcionó, sin errores y publicado sin problemas, y fue solo por casualidad que me encontré con el mensaje de error System.Net.Http, que se muestra en una solicitud de API pequeña, difícil de notar, pero bastante importante sobre el sitio web I '' Estoy trabajando en

Regresé a 4.6.1 y todo vuelve a estar bien.

Answer 8

Puede solucionar esto actualizando su proyecto a .NET Framework 4.7.2. Esto fue respondido por Alex Ghiondea - MSFT . ¡Por favor, véndelo como realmente se lo merece!

Esto está documentado como un problema conocido en .NET Framework 4.7.1.

Como solución alternativa, puede agregar estos objetivos a su proyecto. Eliminarán DesignFacadesToFilter de la lista de referencias pasadas a SGEN (y las agregarán nuevamente una vez que SGEN haya terminado)

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

Otra opción (en toda la máquina) es agregar la siguiente redirección de enlace a 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.

Answer 9

Si tiene varios proyectos en su solución, haga clic con el botón derecho en el icono de la solución en Visual Studio y seleccione ''Administrar paquetes NuGet para la solución'', luego haga clic en la cuarta pestaña ''Consolidar'' para consolidar todos sus proyectos en la misma versión del DLL. Esto le dará una lista de ensamblados referenciados para consolidar. Haga clic en cada elemento de la lista, luego haga clic en instalar en la pestaña que aparece a la derecha.

Answer 10

Sigue los siguientes pasos,

1. Actualice Visual Studio a la última versión (es importante)
2. Elimine todos los redireccionamientos de enlace de web.config

3. Agregue esto al archivo .csproj :

   <PropertyGroup>
     <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
     <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
   </PropertyGroup>

4. Construye el proyecto
5. En la carpeta bin debe haber un (WebAppName).dll.config
6. Debería tener redireccionamientos, cópielos en web.config
7. Elimine lo anterior .csproj archivo .csproj

Deberia de funcionar

Answer 11

Tenía esto, pero fue porque había agregado un paquete NuGet que había actualizado las redirecciones de enlace. Una vez que eliminé el paquete, las redirecciones todavía estaban allí. Los eliminé todos y luego ejecuté update-package -reinstall. Esto agregó las redirecciones correctas.

Answer 12

Tengo el mismo problema y la única forma en que puedo solucionarlo es agregando bindingRedirect a app.confing cómo escribió @ tripletdad99.

Pero si tiene una solución con más proyectos, realmente es una mala idea actualizar cada proyecto a mano (y también a veces después de actualizar algún paquete Nuget, debe hacerlo nuevamente). Y es la razón por la que escribí un script de PowerShell simple que, si todo 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"

Ejemplo de uso:

./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"

Probablemente no sea perfecto y también será mejor si alguien lo vincula a la tarea previa a la compilación.

Answer 13

Verifique la versión del framework .net.
Mi marco .net original es una versión anterior.
Después de instalar .net framework 4.6, este problema se resuelve automáticamente.