c# - run - Cómo usar el Microsoft.Bcl.Async ¿verdad?
return task c# (2)
Use Async Targeting Pack para Visual Studio 11 en su lugar.
Install-Package Microsoft.CompilerServices.AsyncTargetingPack
Si prefiere usar la presentación preliminar de Microsoft.Bcl.Async, deberá agregarla a todos los proyectos. La próxima versión de Bcl.Async debería tener una mejor mensajería para detallar mejor eso.
Si usa VS 2010, lo único que sé que le da asincronización / espera es el AsyncCTP; por lo tanto, no tiene sentido usar Microsoft.Bcl.Async en VS 2010.
actualizar:
WRT to Microsoft.Bcl.Async: el problema en torno a la advertencia de MSB ("no se puede resolver ... dependencia indirecta ..." es conocido y se está abordando. En una actualización futura (a MSBuild y Microsoft.Bcl.Async) esto ser corregido y no tendrá que incluir Microsoft.Bcl.Async en ambos proyectos.
Uso el package Microsoft.Bcl.Async en un proyecto y este proyecto es referenciado por otro proyecto que no usa características asincrónicas.
Ahora recibo esta advertencia de error cuando compilo la solución (o solo el segundo proyecto):
La referencia principal "XYZ.dll" no se pudo resolver porque tiene una dependencia indirecta en el ensamblado de la estructura "System.Runtime, Version = 1.5.11.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" que no se pudo resolver en el objetivo actual marco de referencia. ".NETFramework, Version = v4.0". Para resolver este problema, elimine la referencia "XYZ.dll" o redirija su aplicación a una versión de marco que contenga "System.Runtime, Version = 1.5.11.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a".
Yo uso en ambos proyectos esta app.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:bcl="urn:schemas-microsoft-com:bcl">
<dependentAssembly bcl:name="System.Runtime">
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.16.0" newVersion="2.5.16.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.5.16.0" newVersion="2.5.16.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
¿Qué estoy haciendo mal?
No quiero hacer referencia a los dlls del paquete asincrónico.
No puedo usar el objetivo .Net 4.5. Debe ser .Net 4.
Marco de objetivos para todos los proyectos: .NET Framework 4
Resumen :
Hay un par de soluciones disponibles para usted:
Instale el paquete Microsoft.Bcl.Async en el proyecto de referencia.
Instale el paquete Microsoft.Bcl.Build en el proyecto de referencia. Esto contiene la solución real, y es únicamente una dependencia de tiempo de compilación. Cuando hace esto, debe tener los redireccionamientos de enlace adecuados en la App.Config del proyecto (como la que ha enumerado anteriormente), independientemente de si se trata de una biblioteca de clases, un proyecto web o un ejecutable.
Si no desea una dependencia de ningún paquete, tome el contenido del elemento PropertyGroup dentro del archivo Microsoft.Bcl.targets (instalado con Microsoft.Bcl.Build) e insértelo en la parte inferior del proyecto de referencia después de la última importación. elemento.
Nota: Cualquiera que sea la opción que elija arriba, cuando envía una biblioteca que toma una dependencia de Microsoft.Bcl.Async (como con el antiguo Microsoft.CompilerServices.AsyncTargetingPack), debe enviar esos binarios (System.Runtime, System.Threading). Tareas, Microsoft.Threading.Tasks. *) Con la aplicación / paquete que usa su biblioteca.
Larga historia :
Como Peter señaló, este es un problema conocido que solo ocurre para Microsoft.Bcl.Async y no para Microsoft.CompilerServices.AsyncTargetingPack, debido a la forma en que están diseñados.
Parte del diseño de Microsoft.Bcl.Async era respaldar (a través de un paquete NuGet) algunos nuevos ensamblados .NET 4.5 (System.Runtime, System.Threading.Tasks) para que se ejecutaran en 4.0. A MSBuild no le gusta esto y le hace creer que la biblioteca de referencia ha tomado una dependencia de un ensamblaje de una versión de marco más reciente. La solución en el paquete Microsoft.Bcl.Build corrige esto.