¿Por qué Windows Phone 7 no es totalmente compatible con la especificación C#?

Question

¿Por qué Windows Phone 7 no es totalmente compatible con la especificación C# cuando el único idioma disponible es C#? De acuerdo, puedo entender la falta de soporte "dinámico", pero ¿por qué no se admite la contracovarianza? ¿Por qué las bibliotecas de terceros que nos son familiares y las que utilizamos en los proyectos de escritorios de servidores no son compatibles con el teléfono 7? ¿Qué sentido tiene tener un código de IL intermedio si seguimos aquí?

Answer 1

Windows Phone 7 no es totalmente compatible con todas las características de .NET Framework a las que está acostumbrado porque está construido en Silverlight.

Silverlight fue diseñado para no admitir el conjunto completo de características, ya que está destinado a ser un tiempo de ejecución ligero (en lugar de requerir que cada usuario descargue todo el .NET Framework para ejecutar una aplicación de Silverlight).

Answer 2

Tenga en cuenta que se ejecuta en Compact Framework CLR, que no tiene todas las funciones del escritorio CLR.

EDITAR: Después de un poco de pesca de arrastre, encontré que generic variance isn't supported in the Compact Framework (o al menos no estaba en 2005, y sospecho que no se ha implementado ya que ha habido poco uso hasta hace muy poco):

No es compatible con los modificadores de varianza. Aunque la varianza/co-varianza forma parte de la especificación general de ECMA para genéricos, y se implementa para el .NET CLR completo, no se usa en la Biblioteca de clases base ni en C# y VB.

Bien, entonces no es "totalmente compatible" con C# 4 (la última versión), pero ¿conoce alguna característica del lenguaje C# 3 que no es compatible?

En términos de bibliotecas, se trata de un marco que se basa aproximadamente en Silverlight 3 pero con algunos Silverlight 4 bits, y con varios aspectos del "escritorio" Silverlight eliminado. (EDITAR: Según un enlace en los comentarios, debe contener todos de las API de Silverlight 3. No estoy seguro de si eso es correcto o no ...) En otras palabras, es su propia bestia, realmente. Aunque la propia IL puede ser portátil, es difícil garantizar la compatibilidad cuando se han eliminado varias API. Sin embargo, en muchos casos puede reconstruir las bibliotecas para apuntar a WP7. Estoy de acuerdo en que es molesto tener que hacerlo, pero es mejor que ellos no estar disponibles en absoluto.

EDIT: Las citas de mis reclamos que utiliza el CF CLR:

Windows Phone 7 Series Developer General FAQ:

¿Qué tecnologías y herramientas puedo utilizar para programa para Windows Phone 7 Series?
Actualmente puede utilizar el lenguaje administrado C# utilizando Silverlight y XNA en base a Compact Framework.

¿Puedo usar Windows Forms?
No, Windows Forms no es compatible con la versión de Compact Framework incluida con Windows Phone 7 Series.

(y más adelante)

¿Puedo usar llamadas a las bibliotecas de XNA en Silverlight?
Silverlight y XNA comparten una base de código común en Compact Framework. Si una llamada no está basada en GUI, en la mayoría de los casos se puede compartir entre Silverlight y XNA.

Un CF team member's blog post:

Para los desarrolladores que vienen a Windows Phone 7 (WP7) desde el escritorio de Windows en primer lugar quisiera aclarar que el tiempo de ejecución (CLR) que se ejecuta en el WP7 no es lo mismo como el que se ejecuta en el escritorio. El tiempo de ejecución de WP7 se conoce como .NET Compact Framework (NETCF) y funciona de manera diferente que el "escritorio CLR".

Answer 3

si está utilizando SL, ligarse a un servicio web, a continuación, puede (debe) mantener la aplicación móvil delgado y succionar la grasa en el servidor ...

suena simple sé, pero muchos píos TRATE de delegar todas las responsabilidades a la 'aplicación'; esta es una mala práctica. si su 'sitio web' cumple con REST, entonces debe alinear su aplicación para realizar simplemente llamadas json/xml a su 'costosa' lógica basada en el servidor.

de todos modos, así es como lo hacemos :)