Le differenze sembrano essere minime finché non si svela i livelli per rivelare come funziona davvero Silverlight.
Una persona ha menzionato l'impossibilità di eseguire una chiamata al servizio web sincrono. Altre limitazioni importanti sono che Silverlight gira su un proprio ambiente di runtime dedicato e non può utilizzare le librerie di base .NET. Dipende interamente dalle librerie framework di Silverlight limitate, che per correttezza sono per lo più complete, tuttavia si verificheranno situazioni in cui si vorrà accedere a qualcosa in particolare nella libreria di base .NET che non è disponibile per Silverlight Runtime.
L'altro problema a cui mi sono imbattuto personalmente è il tentativo di riutilizzare le stesse classi di modelli di dati dal mio progetto di servizio web al mio progetto Silverlight. Non è possibile condividere direttamente il progetto o l'assieme binario, poiché viene compilato ed eseguito solo sul framework .NET di base. È possibile duplicare il codice del modello di dati in entrambi i progetti (che presenta i relativi vantaggi di progettazione) oppure creare un progetto Silverlight che fa riferimento a risorse dal progetto del modello di dati effettivo. In questo modo hai due progetti, uno che verrà compilato per l'esecuzione sul framework principale e l'altro per Silverlight. Ancora una volta, non un grosso problema, solo un'altra realizzazione del wtf che ho avuto la prima volta che mi sono imbattuto in.
Ci sono anche limitazioni sulle dimensioni del file XAP che i framework di terze parti sono in grado di gestire in modo abbastanza efficace, ma è qualcosa a cui prestare attenzione.