Perché Windows Phone 7 non supporta pienamente le specifiche C#?

Question

Perché Windows Phone 7 non supporta pienamente le specifiche C# quando l'unica lingua disponibile è C#? Va bene, posso capire la mancanza di supporto "dinamico", ma perché non è supportata la contro-covarianza? Perché non ci sono librerie di terze parti che ci sono familiari e che utilizziamo in progetti server-desktop non compatibili con Phone 7? Che senso ha un codice intermedio IL se finiamo qui?

Answer 1

Windows Phone 7 non supporta completamente tutte le funzionalità di .NET Framework a cui è abituato poiché è basato su Silverlight.

Silverlight è stato progettato per non supportare l'intero set di funzionalità poiché è pensato per essere un runtime leggero (piuttosto che richiedere a tutti gli utenti di scaricare l'intero .NET Framework per eseguire un'applicazione Silverlight).

Answer 2

Tenere presente che è in esecuzione su Compact Framework CLR, che non ha tutte le funzionalità del CLR del desktop. EDITORE: Dopo un po 'di pesca a strascico, ho trovato che generic variance isn't supported in the Compact Framework (o almeno non era tornato nel 2005, e ho il sospetto che non sia stato implementato poiché è stato usato fino a poco tempo fa):

Nessun supporto per i modificatori di varianza. Sebbene varianza/co-varianza faccia parte delle specifiche ECMA complessive per i generici e sia implementata per l'intero CLR .NET, non viene utilizzata nella libreria di classi base o da C# e VB.

Ok, quindi non "supporta completamente" C# 4 (la versione più recente), ma conosci qualche caratteristica del linguaggio C# 3 che non è supportata?

In termini di librerie, si ha a che fare con un framework basato su Silverlight 3 ma con alcuni Silverlight 4 bit e con vari aspetti di Silverlight "desktop" rimossi. (MODIFICA: secondo un link nei commenti, dovrebbe contenere tutte le delle API di Silverlight 3. Non sono sicuro che sia accurato o meno ...) In altre parole, è proprio la sua bestia, davvero. Anche se lo stesso IL può essere portatile, è difficile dare una garanzia di compatibilità quando sono state rimosse varie API. Tuttavia, in molti casi è possibile ricostruire le librerie per scegliere come target WP7. Sono d'accordo che è fastidioso doverlo fare, ma è meglio che non siano affatto disponibili.

EDIT: Citazioni per le mie affermazioni che utilizza il CF CLR:

Windows Phone 7 Series Developer General FAQ:

Quali tecnologie e gli strumenti posso utilizzare per il programma per Windows Phone 7 Series?
Attualmente è possibile utilizzare il linguaggio gestito C# utilizzando Silverlight e XNA basati su Compact Framework.

Posso utilizzare Windows Form?
No, Windows Form non è supportato nella versione di Compact Framework inclusa con Windows Phone 7 Series.

(e successivamente)

Posso usare chiamate di libreria XNA in Silverlight?
Silverlight e XNA condividono una base di codice comune nel Compact Framework. Se una chiamata non è basata sulla GUI, nella maggior parte dei casi può essere condivisa tra Silverlight e XNA.

A CF team member's blog post:

Per gli sviluppatori che vengono a Windows Phone 7 (WP7) dal desktop di Windows Permettetemi innanzitutto chiarire che il runtime (CLR) che è in esecuzione sul WP7 non è la stessa come quello in esecuzione sul desktop. Il runtime di WP7 è noto come .NET Compact Framework (NETCF) e funziona in modo diverso rispetto al "desktop CLR".

Answer 3

se si sta utilizzando SL, il collegamento a un webservice, allora si può (dovrebbe) mantenere l'applicazione mobile magro e succhiare il grasso sul server ...

sembra semplice lo so, ma molti fa riflettere a delegare tutte le responsabilità all'app: questa è una cattiva pratica. se il tuo 'sito web' è compatibile con REST, allora dovresti allineare la tua app semplicemente per effettuare chiamate json/xml alla tua logica 'costosa' basata su server.

in ogni caso, questo è come lo facciamo :)