¿Qué características de .Net/WPF echas de menos cuando trabajas en Silverlight?

Question

Recientemente comencé a trabajar con Silverlight e inmediatamente noté la diferencia entre el BCL de Silverlight y el .Net y WPF completos. Para algunos de ellos, encontré excelentes soluciones publicadas en línea por otros desarrolladores, y otras fueron más complicadas. ¿Qué características/clases le sorprendieron/decepcionaron al encontrar ausentes de las bibliotecas de clases de Silverlight, y qué hizo para evitarlas?

Algunos de los míos eran:

1. Ningún evento provocó animaciones - He creado una clase de ayuda con los métodos estáticos para unir cada tipo de animación que he usado para guiones gráficos en una biblioteca compartida, y en el nivel de aplicación. Creo clases con métodos estáticos para ponerlos todos juntos como lo hubiera hecho en XAML si trabajara en WPF. Hasta ahora, esta ha sido una buena solución para mantener mis animaciones organizadas y la lógica fuera de mis controladores de eventos.
2. ScrollViewer no es compatible con la rueda del mouse - Adam Cooper creó una excelente biblioteca de clases que agrega esta funcionalidad que requiere el mínimo de código para implementar en cualquier proyecto de Silverlight. Su sitio parece estar inactivo en este momento, así que aquí hay un enlace al blog de Tim Heuer que lo explica y lo vincula (para que esté disponible cuando su sitio vuelva a estar en línea). Add mouse wheel support to ScrollViewer in Silverlight
3. SortedDictionary<T, K> falta. Encontré this post que contiene una implementación, pero no terminé usándolo yo mismo.
4. ResourceDictionary.MergedDictionaries no está disponible - Una vez más ... encontré a alguien que implementó esto y publicó el código fuente, pero parecía ser un poco complicado. Probablemente lo resolveré un poco, pero todavía tengo que hacerlo. MergedDictionaries in Silverlight
5. La propiedad de ZIndex solo está disponible en el objeto Canvas. Publiqué esto como una pregunta aquí en SO, y alguien hizo una gran sugerencia para envolver mis contenedores en una colección si eso es lo que se necesita. Se siente un poco descuidado, pero debes hacer lo que tienes que hacer. Mis contenedores están anidados a tres niveles de profundidad, por lo que podría necesitar deformarlos todos en objetos Canvas y configurar el Canvas.ZIndex tres veces para cada evento. Feo como el pecado, pero si es el único, entonces que así sea.

Me interesan los otros problemas comunes que los desarrolladores de Silverlight con más experiencia han encontrado y lo que ha hecho para solucionarlos.

Answer 1

¿Por dónde empiezo? :)

• Sin MultiBinding
• Sin ElementName = vinculante
• TemplateBinding sólo puede referirse a las propiedades directas, no adjunta de DP
• Sin RelativeSource vinculante
• Sin vinculante para las propiedades secundarias - por ejemplo , {Binding Path=Foo.Bar[0].Baz}
• Sin posibilidad de suscribirse a eventos cambiado sobre cualquier propiedad de dependencia arbitraria - el autor de clase tiene que definir explícitamente un evento (y en la mayoría de los casos, sólo una o dos propiedades en los controles SL realmente hacen)
• El Visual State Manager requiere que el autor de control para conocer todos los estados de estilo-poder cuando el control está escrito, que rompe por completo la "extensión a través de estilos/plantillas, no la herencia" historia que WPF promueve
• no Adorners
• Sin Navegación
• Sin herencia propiedad de dependencia
• n/apoyo va a trompicones ResourceDictionaries/diccionarios fusionadas externos
• historia Validación chupa (que es sólo marginalmente mejor en WPF)
• para la impresión
• <Setter .. Value="{Binding ...}" /> no es compatible

Además de eso, varias firmas de métodos cambiaron sin una buena razón. Por ejemplo, IIRC, las sobrecargas para Dispatcher.Invoke son diferentes, en lugar de que SL ignore los parámetros que aún no puede manejar. O como otro ejemplo, ObservableCollection en WPF puede generar Agregar, Eliminar, Reemplazar y Mover eventos - en SL solo son los tres primeros.

Como escribo el código para trabajar en ambas plataformas, el código termina siendo plagado de patrones de estrategia y #ifdefs. Se siente como C++ todo de nuevo :-)

Answer 2

La mayor queja que tengo es la falta de soporte completo para todos los enlaces WCF disponibles. Solo el hecho de poder utilizar BasicHttpBinding a menudo significa que una solución Silverlight a un problema no es una opción válida.

Answer 3

Probablemente, el soporte para sockets o UDP no sea el mayor problema para mí, seguido de las clases de cifrado que faltan.

Además, las clases perdidas como StringDictionary y ApplicationException a las que te acostumbras y luego no encuentras son una molestia. En general, es posible encontrar un sustituto o una solución, pero personalmente preferiría que la descarga de Silverlight fuera de 5MB a 6MB, así que no tuvimos que hacerlo ;-).

Un truco realmente útil que vi en un blog que me permitió reutilizar mis ensamblajes .Net normales fue agregar elementos existentes como un enlace. En varios casos ahora tengo dos archivos de proyecto que usan los mismos archivos de clase con un objetivo .Net 3.5 y el otro el tiempo de ejecución de Silverlight. Estoy extremadamente agradecido de haber encontrado ese truco ya que ya estaba comenzando a recorrer el camino de crear diferentes bases de código para .Net 3.5 y Silverlight!

Answer 4

Sin soporte 3D.

Answer 5

Como diseñador, la falta de desencadenantes de eventos/propiedades es por lo que desempoderamiento.

no soy chico C#/oop así que cuando tengo a desencadenar una serie de guiones gráficos cuando se hace clic en un artículo o cargas de un botón o después de otros acabados storyboard, tengo que llamar a los desarrolladores en :(

Answer 6

Al parecer, comentar sobre el comentario de Felixthehat requiere una cierta reputación.

Pero me gustaría secundar su llamada para desencadenantes de eventos/propiedades ... El marco Triggers en WPF me permite hacer cosas realmente poderosas como diseñador de interacción sin tener que sumergirse en el código. Lo extraño.

Answer 7

Aquí hay algunas cosas que me encontré cuando me convertí una aplicación de WPF a Silverlight:

1. clase de enumeración es diferente ... No se puede hacer esto en Silverlight (puede en WPF) para unirse a una enumeración:

   HoleType1.ItemsSource = Enum.GetValues ​​(typeof (Hole.HoleTypes));

2. colores cepillo funcionan de forma diferente ...

WPF:

protected Brush _CurrentHoleColor = Brushes.Red; 

Silverlight:

protected Brush _CurrentHoleColor = new SolidColorBrush(Colors.Red); 

3. no han funcionado éste hacia fuera todavía, pero hay algo diferente este código WPF que había utilizado para comprobar dónde se hizo clic en el ratón:

System.Windows.Media.VisualTreeHelper.HitTest(canvas1, p); 

4. Creo que algo es ligeramente diferente acerca de las sobrecargas utilizados para la creación de nuevos temas con

this.Dispatcher.BeginInvoke(....) 

Answer 8

de Silverlight estilos inmutables y la falta de diccionario de fusión es también un gran uno - si usted está escribiendo controles, estos dos le dan un montón de problemas - sin mencionar los archivos genéricos.xaml inmanejables.

Answer 9

Además de la lista excelente Paul Stovell 's:

• No hay extensiones de marcado personalizados.
• No x:Type extensión de marcado.
• No LayoutTransform (aunque hay workarounds).
• No hay metadatos de conveniencia para DependencyProperties (tiene que definir manualmente medida/organizar/renderizar invalidación, cambios de propiedad, etc.).
• No liviano Drawing o DrawingContext clases (tienen que usar Shape elementos).
• Sin comandos.

Answer 10

Perspectiva en 3D es genial, pero no puedo esperar a 3D real!

Answer 11

• ScrollViewer tiene ningún evento de cambio (usted tiene que utilizar un corte de unión)
• hay ningún explorador independiente del soporte de menú de contexto hasta la versión 4
• Limited DocumentFlow apoyo
• No hay soporte MD5 (pero el más moderno algoritmos hash en su lugar)
• WebClient no le permite realizar solicitudes autenticadas HTTP.

Mi mayor motivo favorito:

• nido de espacios de nombres de una rata