C # è in realtà un linguaggio multipiattaforma?

C # (e la piattaforma .net in generale) sembra che stia diventando una buona opzione per le app multi-targeting:

• framework MS ufficiale .net: sviluppo di windows a tutto campo, sviluppatore asp.net, sviluppatore Windows Phone, ecc.

• mono e tutti i suoi derivati: monotouch, monodroid: il resto del mondo. Questi strumenti sono oggi RTM.

• Significa che C # sta diventando un buon linguaggio per il targeting delle piattaforme più popolari: desktop, web e mobile?

• È ancora meglio usare il linguaggio "nativo" delle piattaforme target (obiettivo C, Java, ecc.)
• È solo uno schermo di fumo e solo un linguaggio di marketing?

Tieni presente che in realtà sono consapevole che non sarò in grado di copiare / incollare il codice tra piattaforme. Ma sono sicuro che i livelli inferiori di applicazioni (modelli, business, ecc.) Possano essere riutilizzati, ma so che dovrò adattare i livelli superiori (Gui, ecc.) Alla piattaforma. Il mio obiettivo è più focalizzato sulle competenze richieste rispetto alla condivisione di codice tecnico.

[modifica] Io sono ac # sviluppatore in un'azienda che utilizza massicciamente c #. Ecco perché ho parlato di c # in un piano per espandere la gamma di piattaforme target nella mia azienda.

Sì, in generale .NET Framework è ottimo per le app destinate a un'ampia gamma di dispositivi. Ma questo non è unico per .NET; Java lo stava facendo molto tempo prima. La cosa da tenere a mente è che non esiste una vera alternativa agli strumenti nativi per una particolare piattaforma.

Le applicazioni Mac create con .NET non appariranno mai come applicazioni native per Mac OS X, e questo è considerato un problema dalla stragrande maggioranza degli utenti di OS X. Questo potrebbe non essere importante per te strategicamente, a seconda che il tuo modello di business valuti la massimizzazione della saturazione rispetto alla massimizzazione della soddisfazione dell'utente, ma è certamente qualcosa da tenere a mente quando fai una scelta.

I sistemi di interfaccia grafica in Linux e Windows sono in qualche modo più flessibili in termini di applicazioni che sembrano "native" e si adattano bene alla piattaforma. Ma lo biasimo principalmente per la mancanza di chiare linee guida per l'interfaccia e per il fatto che gli sviluppatori di applicazioni sono stati storicamente disposti a ignorare quelli che esistono. Molti utenti Mac preferiscono il Mac proprio per la sua interfaccia utente coerente.

Considerando che dovrai adattare il livello GUI alla piattaforma specifica (e possibilmente riscriverlo in una lingua completamente diversa, come Objective-C), che ti consente di sfruttare la piattaforma .NET solo per il codice della libreria. E poi, secondo me, non c'è una vittoria molto chiara per C # su C ++.

Per un rapido sviluppo delle applicazioni, esistono poche alternative migliori di C # e .NET. E spingere fuori un'app rapidamente e averla immediatamente disponibile su una varietà di piattaforme è sicuramente un vantaggio commerciale. Ma per le vere applicazioni multipiattaforma che mirano a soddisfare veramente l'utente, non è necessariamente la soluzione del proiettile d'argento.

Microsoft .NET è l'implementazione ufficiale di CLR, DLR, BCL, CLI e CLS. Altre società, gruppi, comunità o gruppi di lavoro non sono associati a Microsoft in modo tale che questi possano avere un'implementazione 1: 1 dell'ultima versione del framework e del linguaggio.

Fondamentalmente, è necessario rivedere quale lingua e funzionalità del framework si desidera sfruttare in un progetto concreto e verificare se sono presenti in implementazioni .NET non ufficiali.

Se ti aspetti una soluzione di compilazione e distribuisci ovunque, ti sbagli: devi fare un case study.

Uso C # su giochi in esecuzione su XBOX e macchine Windows, lo uso in app Compact Framework per soluzioni di robotica, utilizzo MonoTouch per lo sviluppo di iPad, ho alcune app Web in esecuzione su Linux e poche altre soluzioni. Di solito c'è un modo per fare le tue cose su una determinata piattaforma. Lo strato centrale è pressoché lo stesso per la maggior parte di essi (caso di studio effettivamente necessario). Il problema - e lo considero come uno di serie - è l'ambiente di sviluppo. Sono abituato a Visual Studio e alle sue funzionalità. Ma MonoDevelop per esempio mi fa impazzire.