online example c# wpf silverlight

c# - example - wpf to html5



Error de compilaciĆ³n desconocido No se puede resolver la dependencia a System.Windows (5)

En su archivo [projectName] .csproj, puede identificar la dependencia no resoluble y eliminarla antes de volver a agregarla.

  • Este fue mi error: v4.0.30319 / Microsoft.WinFx.targets (268,9): error MC1000: error de generación desconocido, ''No se puede resolver la dependencia del ensamblado'' Microsoft.Data.Schema '', ...
  • en mi archivo .csproj identifiqué la línea de referencia con la palabra clave ''Microsoft.Data.Schema''
  • borré la línea y mi proyecto pudo ser compilado nuevamente.

Espero que ayude a otros

Acabo de descargar el código fuente de PoshConsole y estaba tratando de construir la solución. Inicialmente tuve dos problemas:

  1. el System.Interactivity.dll no se pudo resolver. Instalé Blend 4 SDK y ese problema se solucionó.

  2. Error de compilación desconocido: no se puede resolver la dependencia de System.Windows

En este momento, cada vez que intento construir el proyecto, aparece el siguiente error en dos proyectos en la solución y no he podido encontrar una solución después de buscar en Google.

No se puede resolver la dependencia del ensamblado ''System.Windows, Version = 2.0.5.0, Culture = neutral, PublicKeyToken = 7cec85d7bea7798e'' porque no se ha cargado previamente. Al utilizar las API ReflectionOnly, los ensamblados dependientes deben cargarse o cargarse previamente a petición a través del evento ReflectionOnlyAssemblyResolve.



He recibido este mensaje de error para otro ensamblaje (no GAC, personalizado).

En mi caso, la situación fue la siguiente:

  • conjunto X contiene clase A
  • el conjunto Y contiene la clase B, que hereda de A
  • conjunto Z contiene una plantilla de datos para la clase B

Y referenciado X, Z referenciado Y.

El mensaje de error apuntaba a la línea en la plantilla de datos en Z donde se hacía referencia a B, y señalaba que X no se podía cargar.

La solución era hacer que Z también hiciera referencia a X. Aparentemente, el compilador no puede resolver esa referencia transitiva para cargar los ensamblajes necesarios por sí mismo.


Me gustaría agregar algo de información además de la respuesta de que sugiere agregar una referencia al ensamblado que se indica mediante el error del compilador.

Experimenté el mismo problema mientras trabajaba en un proyecto de WPF. Teniendo en cuenta la relación X, Y, Z presentada en la respuesta, en mi caso, ocurre cuando enlace propiedades con tipos de X a una vista que utiliza la plantilla de datos de Z. Por lo tanto, esto no ocurre con todos los ensamblajes que están referenciados por Z, pero solo aquellos que exponen sus tipos en Z Views. En mi caso, estaba vinculando SelectedItem de un ComboBox a una enum declarada en Z.

Puede refactorizar estos tipos para objetar y el problema desaparece si realmente desea conservar las referencias como deberían, especialmente si usa MVVM. Además, en ViewModel expongo las propiedades que envuelven las propiedades de los objetos usados, ya que es posible que no estén listas para la vista.

Espero que esto ayude.


Voy a agregar y responder esta vieja pregunta, en caso de que alguien se encuentre con el mismo problema.

Hace poco estuve trabajando en un programa heredado y tuve este error. La solución no fue aparente.

Problema

Uno de los paquetes NuGet a los que se hizo referencia se creó para un conjunto de bibliotecas internas y se almacenó en el repositorio interno de NuGet.

Las aplicaciones compilaron bien en VS2013, debido a todas las referencias de NuGet que tienen en los archivos del Proyecto, directamente a las bibliotecas.

Cuando estas referencias se cambiaron a (No es compatible con HintPath), muchos de estos paquetes NuGet no se crearon de acuerdo con nuspec. No hubo una carpeta lib .

Los paquetes se rehicieron para seguir la especificación, sin embargo, varios de los paquetes tenían bibliotecas antiguas de Silverlight incluidas en ellos. Estas bibliotecas estaban causando el error.

Solución

Después de nuspec , la carpeta lib tenía subcarpetas creadas: net45 y sl4. .NET4.5 y Silverlight4.0 respectivamente.

Cuando los paquetes fueron reemplazados por los nuevos, las construcciones funcionaron bien. Independientemente de la versión del archivo del proyecto.

TL; DR

Antigua estructura nupkg:

Package.1.0.0.nupkg - Library.Net40.dll - Library.Sl4.dll

Nueva estructura nupkg:

Package.1.0.1.nupkg - lib - net45 - Library.dll - sl4.0 - Library.dll