exception - servicemodel - no se puede cargar el archivo o ensamblado system runtime serialization primitives

No se pudo cargar el archivo o ensamblar System.Net.Http.Primitives. La definición del manifiesto del conjunto ubicado no coincide con la referencia de ensamblaje (14)

Estoy trabajando en un programa que usa la API de Google. Sin embargo, cada vez que ejecuto mi programa, sigo recibiendo el siguiente error:

No se pudo cargar el archivo o ensamblado ''System.Net.Http.Primitives, Version = 1.5.0.0, Culture = neutral, PublicKeyToken = b03f5f711d50a3a'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje.

Estoy usando Visual Studio 2012 Express. Intenté seguir este link y revisé muchos foros, pero ninguno parece funcionar. El principal problema parece provenir del archivo DLL "Google.Apis.dll" al que hice referencia, y hace referencia a System.Net.Http.Primitives v1.5.0.0. Sin embargo, la versión a la que hace referencia mi programa es 2.2.13.0. Intenté tener la referencia del programa v1.5.0.0 en su lugar (me las arreglé para encontrar el dll junto con el código fuente de Google.Apis), pero esto solo causó otro problema en el que necesitaba una versión más reciente de System.Net. Http.Primitives.

He estado tratando de encontrar una forma de evitar esto, sin embargo, parece que no puedo encontrar nada que funcione. Gracias por el tiempo

Agregue lo siguiente a su web.config (app.config):

<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-4.2.13.0" newVersion="4.2.13.0"/> </dependentAssembly> </assemblyBinding> </runtime>

De alguna manera, la respuesta popular de Paul Lemke no funcionaba para mí. El proyecto es una aplicación de formularios web que comenzó con .net v 2.0 y se ha actualizado a .NET versión 4.5

Actualicé los paquetes y nuget creó el AssemblyAndirectory / bindingRedirects correcto.

Según algunos de los comentarios, probablemente no sea la mejor idea cambiar su archivo machine.config local.

A propósito, tenía un atributo en mi archivo web.config que causaba que la aplicación ignorara los bindingRedirects.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

Eliminé ese atributo xmlns y comenzó a funcionar.

En mi caso, Nuget automatic add following to web.config

Pero todavía tengo el mensaje de error anterior, finalmente lo resuelvo. Debe copiar esas etiquetas en el archivo machine.config ubicado en C: / Windows / Microsoft.NET / Framework64 / v4.0.30319 / Config / machine.config.

Para encontrar la etiqueta de "runtime" en machine.config, reemplace o agregue (si no hay tal etiqueta) con sus etiquetas de su web.config (las que he enumerado anteriormente).

En mi caso, estaba haciendo referencia a los paquetes NuGet de una biblioteca de clase. NuGet no nos informa que la aplicación de la biblioteca de la clase app.config se ignora por completo y tenemos que copiar manualmente su contenido a la aplicación .exe de .exe.

Estábamos teniendo el problema similar. Pero en mi caso, la solución de modificar el app.config de Paul no funcionó. La razón es que lo estoy usando como un complemento dentro de otra aplicación. Por lo tanto, considera el archivo de configuración de esa aplicación. Así que obtuvimos el código api de Google de GitHub y creamos la biblioteca Google.Apis.Core después de eliminar la dependencia de System.Net.Http.Primitives. Luego usamos ese DLL que resolvió nuestro problema.

He tenido un problema similar.

Intente actualizar nuget (herramientas / extensiones y actualizaciones ...) Resolvió eso y algunos otros problemas para mí.

/ Jonas

La respuesta anterior sobre ensamblaje de ensamblaje es correcta, pero NO debe tocar la máquina. Config.

El ensamblaje de ensamblaje debe establecerse en el archivo de configuración de todos los ensamblados EJECUTABLE de su proyecto (.exe.config) que hacen referencia a su biblioteca, y no en los ensamblados de la biblioteca (.dll.config)

Lo que funcionó para mí fue simplemente instalar las "Bibliotecas cliente Microsoft Http" de Nuget.

Me encontré con el mismo problema con la API de Google. El problema principal aquí es que si instala las bibliotecas de cliente Http de Microsoft , coloca en su proyecto una versión actualizada de la DLL System.Net.Http.Primitives. El web.config asume que todavía está usando la versión predeterminada de 1.5. Hay dos cosas que deben suceder para solucionarlo:

Primero: actualice a las últimas versiones de la API de Google y de las bibliotecas de Microsoft Http Client . Puede instalar las actualizaciones a través de NuGet. Haga clic derecho en su sitio web, haga clic en "Administrar paquetes NuGet", seleccione Actualizaciones a la izquierda. En el momento de esta publicación, algunas de las API de Google son solo de presentación previa. Puede instalarlos a través de NuGet seleccionando "incluir presentación" en la parte superior izquierda de la pantalla de actualización.

Segunda actualización / agregue un ensamblado dependiente a su web.config. Para hacer esto, necesita conocer la versión de System.Net.HTTP.Primitives.dll que se instaló. Busque en su directorio bin dentro del Explorador de Windows. Busque System.Net.HTTP.Primitives.dll, haga clic derecho en él, seleccione propiedades y haga clic en la pestaña "Detalles". Tenga en cuenta la versión que se encuentra allí. En el momento de esta publicación, la mía era 4.0.10.0 .

A continuación, agregue / actualice una sección dependiente del ensamblaje para la versión correcta.

<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0"/> </dependentAssembly> </assemblyBinding> </runtime>

Me encontré con este problema cuando lancé mi código que usa Google.Apis.Drive.v2 (v1.9.2.1860) a la empresa para la que trabajo. Les di el exe y todas las DLL que Visual Studio (y NuGet) generaron, y obtuvieron el error. Nunca recibí el error.

La solución fue fácil (una vez que me di cuenta): al instalar la API de Nuget, el archivo ''assemblyname.exe.config'' se genera automáticamente en la carpeta de salida (aka, Debug o Release). Todo lo que tiene que hacer es incluir ese archivo cuando está ejecutando el ensamblado en algún lugar que no sea la carpeta en la que se generó. Aquí está el código para ese archivo para mí:

<?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.2.29.0" newVersion="4.2.29.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

Esta es básicamente la "segunda" solución de Paul, pero el administrador del paquete la genera automáticamente. El problema para mí fue cuando probé su "primera" solución actualizando a Google.Apis.Auth y Google.Apis.Core (v1.9.3) empeoró las cosas. Me daría el mismo error, excepto que ahora era para "Google.Apis.Core" la versión incorrecta (aunque eso probablemente podría haberse resuelto también al incluir el mismo archivo .exe.config).

Espero que esto ayude a alguien, sé que este hilo es bastante antiguo, pero es a lo que me llevó una búsqueda rápida en Google.

Editar: Olvidé mencionar, esto es relevante para una aplicación de consola que se dirige a .NET 4.5. Algunos de ellos probablemente todavía sean relevantes para otros objetivos .NET o ASP.NET, pero no estoy seguro. Su experiencia puede ser diferente.

NuGet hizo el siguiente cambio en Web.Config

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

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

Esto fue después de la instalación y posterior eliminación (por reversión de control de versión) de este paquete https://www.nuget.org/packages/Microsoft.AspNet.WebApi.MessageHandlers.Compression/

Para mí funcionó lo siguiente:

En Visual Studio (2012)> Herramientas> Administrador de paquetes Nuget> Consola de administrador de paquetes. Además del paquete Manager Console, tengo Package Source: nuget.org Proyecto predeterminado: el proyecto que requiere System.Net.Http.Primitives Mirando dentro del archivo de proyecto (yourproject.csproj) con un editor, leo qué versión es necesaria (en mi caso fue Microsoft.Net.Http.2.2.28)

Así que fui a https://www.nuget.org/packages/Microsoft.Net.Http/ y hice clic en mi versión en "Historial de versiones" (desplacéte un poco la página si no la ve). Después de elegir la versión, copia el comando sugerido, en mi caso fue:

Install-Package Microsoft.Net.Http -Version 2.2.28

pero si necesita la última versión es solo esta:

Install-Package Microsoft.Net.Http

y lo pega en su Consola del Administrador de paquetes de Visual Studio abierta anteriormente como describí anteriormente. Ejecuta el comando.

En el proyecto bajo las referencias, System.Net.Http.Primitives ahora se ha actualizado.

Pude resolver esto bastante fácilmente. Acabo de abrir el Administrador de paquetes de Nuget y actualicé el paquete de la biblioteca de cliente de Microsoft ASP.NET Web API 2.2. Esto actualizó Microsoft.Net.Http a la versión más reciente que resolvió el problema con la Asamblea System.Net.Http.Primitives de poder ubicarse. ¡Espero que esto ayude!

Tuve un problema similar con los scripts de PowerShell para TFS 2017. Los scripts llamaron al código .NET para realizar acciones personalizadas durante los procesos de compilación. Seguí recibiendo errores sobre los conflictos de la versión dll.

No pude resolver el problema hasta que implementé un gancho en el evento AppDomain AssemblyResolve según esta respuesta: Hacer que los redireccionamientos vinculantes funcionen para los complementos de la oficina

Esta solución forzó al proceso a usar dlls desde la ruta actual. Sé que esto es algo así como un truco, pero había leído que al ejecutar PowerShell, no siempre se pueden usar los redireccionamientos de enlace, que es lo que originalmente pensé que podía intentar: https://github.com/google/google-api-dotnet-client/issues/555