Parece que está haciendo referencia tanto a los metadatos del SDK de Windows 10 (UAP) como a los metadatos del SDK de Windows 8.1 (Windows). ¿Está mezclando archivos binarios antiguos y nuevos, o un archivo de proyecto antiguo? Intenta crear un nuevo proyecto desde cero y agrega tus fuentes.

Me encontré con algo similar:

No es divertido. Creo que comenzó cuando accidentalmente agregué un método de extensión a un conjunto de utilidades que guardo en un proyecto de biblioteca de clases portátil que hacía referencia al using Windows.ApplicationModel.DataTransfer; , ya que (estúpidamente) agregué un código que accedió al portapapeles a la PCL. Y eso tiene algún sentido; ahora estoy apuntando efectivamente a dos plataformas de Windows, lo que obviamente es incorrecto.

Se agregaron algunas cosas al archivo csproj de ese proyecto PCL. Primero fue esta línea:

 <UseVSHostingProcess>false</UseVSHostingProcess>

El segundo fue este ItemGroup:

 <ItemGroup> <Reference Include="Windows.Foundation.UniversalApiContract"> <HintPath>..\..\Program Files (x86)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\2.0.0.0\Windows.Foundation.UniversalApiContract.winmd</HintPath> </Reference> </ItemGroup>

No estoy seguro de si todo esto era necesario, pero eliminé el código relacionado con el portapapeles, la referencia a Windows.ApplicationModel.DataTransfer; en my using s, y restablecí/eliminé los cambios en el archivo csproj.

Todavía tenía muchos de los mismos errores, sin embargo. Descubrí que hacer reconstrucciones limpias no siempre funciona como esperaba, así que creé un archivo .bat que guardo en la raíz de la carpeta del proyecto de inicio para ejecutarlo cuando tengo problemas. Primero tengo que cerrar la solución en Visual Studio, y luego ejecuto...

 cd C:\Projects\solutionName\projectName cd ./bin rmdir x64 /S /Q rmdir x86 /S /Q rmdir ARM /S /Q cd ../obj/ rmdir x64 /S /Q rmdir x86 /S /Q rmdir ARM /S /Q cd .. pause

Ahora también tengo que ejecutar eso (nuevamente, con la solución cerrada) antes de construir y enviar a la tienda. No estoy muy seguro de por qué, pero hacer ambas cosas (eliminar el código que no es PCL y restablecer el proyecto PCL y eliminar esas carpetas /bin y /obj ) solucionó el problema.

Mi corazonada no científica de por qué tengo que eliminar /bin y /obj es que VS no siempre parece construir mis proyectos en orden de dependencia y, a menudo, hace referencia a compilaciones anteriores de mi código cuando debería haber comenzado de nuevo. Destruir cualquier posible muleta anticuada parece forzarlo a hacer las cosas de la manera correcta. ¯\_(ツ)_/¯