Esiste un modo supportato per eseguire nativamente le applicazioni .NET 4.0 su un Mac?

11

Quali sono le opzioni supportate da Microsoft per l'esecuzione nativa del codice C # /. NET 4.0 sul Mac? Sì, conosco Mono, ma tra l'altro è in ritardo rispetto a Microsoft. E Silverlight funziona solo in un browser web. Neanche una soluzione di tipo VMWare la taglierà.

Esiste una risposta semi-autorevole al perché Microsoft non supporta .NET sul Mac stesso? Sembrerebbe che potrebbero Silverlight e / o acquistare Mono e essere subito lì. Non è necessario Visual Studio nativo; la compilazione incrociata e il debug remoto vanno bene.

Il motivo è che dove lavoro c'è una crescente quantità di incertezza sul futuro che sta causando molto più sviluppo da fare in C ++ anziché in C #; nuovi progetti stanno scegliendo di usare C ++. Nessuno vuole dire "scusa" al management tra 18 e 24 mesi se il Mac (o l'iPad) dovesse diventare un requisito. Il C ++ è visto come l'opzione più sicura, anche se (probabilmente) significa una perdita di produttività oggi.

c# .net mac mono

— Ðаn
fonte

2

Supportato da chi?

Perché ti interessa davvero se la SM lo supporta? IMO dovrebbe importare di più se Apple lo supporta se vuoi scegliere come target Mac.

— alternativa il

Andare con C ++ non è una cattiva idea. È possibile disporre di una base di codice portatile e utilizzare la GUI nativa su ciascuna piattaforma.

— mike30,

1

Per aggiornare questo post sembra che MS l'abbia notato e che inizieranno a supportare .NET su diversi sistemi operativi, anche se non è chiaro come sarà fatto. Puoi creare applicazioni multipiattaforma con .NET utilizzando NOV: nevron.com/products-open-vision.aspx (lavoro per questa azienda). In genere ti consente di programmare in C # su Windows e quindi compilare per Wpf, MAC, Silverlight e presto per iOS e Android. Esiste un'edizione gratuita (community) di questo prodotto, quindi non è necessario sacrificare la produttività e attenersi al C ++ arcano.

— Bob Milanov,

17

c'è una risposta semi-autorevole al perché Microsoft non supporta .NET sul Mac stesso?

La risposta migliore è probabilmente che non "supporti semplicemente" .NET su Mac. Spendi centinaia di milioni di dollari e diversi anni porting .NET su Mac.

Mentre alcune cose sono completamente gestite e non richiedono il porting, la maggior parte sono involucri attorno all'API Win32 (windows, controlli, gdi +, crittografia, active directory, COM, servizi aziendali, accesso al dispositivo, audio, video, codec, winforms, ecc. eccetera).

Ognuno di questi dovrebbe essere estratto nel backend e rimappato in equivalenti librerie native su OSX. Naturalmente, non ci sarà una buona mappatura pulita, quindi devi anche scrivere hack su hack per farlo funzionare esattamente allo stesso modo.

Quindi c'è il problema che queste API su OSX possono essere fragili e Apple non è molto brava nella retrocompatibilità, quindi puoi rifare i tuoi hack con ogni versione principale (e talvolta release minori e hotfix), accumulando un alto costo di manutenzione.

Fondamentalmente, è un'enorme quantità di denaro e lavora per un guadagno molto piccolo su una piattaforma il cui proprietario sarebbe comunque contrario a farlo. E non vuoi davvero spendere soldi per aiutare le persone a migrare dalla tua piattaforma verso quella di un concorrente.

Quindi ti rimangono scelte tra piattaforme non perfette:

C ++, che richiederà comunque il porting in futuro
Silverlight fuori dal browser, per il supporto Microsoft
Mono, che svolge il compito di supportare un sottoinsieme integro di .NET, ma non è Microsoft

— jpobst
fonte

5

You spend hundreds of millions of dollars and several years porting .NET to the Mac.Mi scusi? Quel numero suona un po 'alto ... Sono abbastanza sicuro che il Mono-Framework (con supporto per molti più SO) non sia costato così tanto.

— Bobby,

1

@Bobby: questo è quello che sto pensando. Mono + Silverlight sembra quasi tutto lì. Aggiungete a questo un po 'di P / Invoke e / o C ++ / CLI per cose meno mainstream (crittografia, annuncio pubblicitario, ecc.) E penso che avreste una soluzione abbastanza ragionevole a costi ragionevoli. La mia tesi è che Microsoft vuole spendere soldi per aiutare le persone a salire su OSX; in caso contrario, le persone smetteranno di usare C # /. NET su Windows.

— Ð

@ Dan: Esatto, Microsoft non vuole essere compatibile con il mondo, altrimenti il mondo potrebbe usare qualcosa di diverso. ;)

— Bobby,

15

Il framework Mono non è inoltre una soluzione completa, completamente testata, documentata e supportata. C'è una differenza tra ciò che è "abbastanza buono" per l'open source e la qualità che le persone si aspettano da Microsoft. Costerebbe facilmente centinaia di milioni di dollari per farlo al livello richiesto dagli utenti. Quello che potrebbero fare per ridurre l'investimento sarebbe quello di scegliere un sottoinsieme popolare (e portatile) del framework .NET e farlo. È quello che hanno scelto di fare, lo chiamano "Silverlight".

— jpobst,

@jpobst ma sembra che MS abbia fatto proprio questo ... e altro ancora?

— Ð

14

No, Silverlight è l'unica opzione Microsoft di .Net su OS X. Mono non "ritarda" quanto pensi; supporta, ad esempio, Net 4.0 e C # 4. Tuttavia, i toolkit UI (WinForms e WPF) non sono ben supportati su OS X. Mono non supporta affatto WPF. Né Microsoft potrebbe riscrivere senza riscrivere l'intero motore di rendering. Probabilmente va bene, però. Se vuoi scrivere un'app Mac nativa, dovresti scrivere un'interfaccia utente nativa (forse usando MonoMac).

— Barry Wark
fonte

La gestione non sembra molto incline ad andare d'accordo con l'opzione Mono. E certamente non supportava .NET 4.0 lo stesso giorno di Windows (o?).

— Ð

Silverlight non è già in gran parte presente sul fronte WPF (-like)? Sì, XAML dovrebbe essere diverso per ottenere un aspetto grafico del Mac.

— Ð

2

@Dan: il modo in cui Mono si sposta in questi giorni, se inizi a sviluppare un'app per l'ultima versione di .NET quando Microsoft la rilascia, Mono supporterà quella stessa versione quando l'app sarà pronta per la spedizione.

— Anon.

@Dan SL e WPF sotto le coperte stanno tentando di unire il più possibile. Ci sono differenze tecniche ma i concetti fondamentali sono multipiattaforma.

— Aaron McIver,

6

Se la gestione della tua azienda non è disposta a utilizzare Mono, non sarai in grado di fare in modo che un'applicazione desktop scritta in C # 4.0 sia così semplice.

— Ramhound,

5

No. Mono è la tua scommessa migliore.

Anche altri progetti open source come DotGNU potrebbero esserti utili. http://www.gnu.org/software/dotgnu/ Ma nessuno di questi è supportato da MSFT.

— Ishpeck
fonte

4

Silverlight non è solo un browser . Dalla versione 3 OOB esiste e sarebbe la strada che prenderei se una piattaforma supportata da Microsoft è un must.

Mentre Mono potrebbe essere in ritardo, non è così rimosso dallo stack .NET come si potrebbe pensare e non dovrebbe essere messo da parte come opzione praticabile.

Per quanto riguarda il motivo per cui Microsoft non implementa l'intero stack .NET; ROI.

— Aaron McIver
fonte

Ma sembra che siano così vicini a Silverlight ... perché non finire il lavoro? Sembrerebbe molto meglio per tutti rispetto al

— retroingegnerizzazione

1

SL non è l'intero stack .NET. Il runtime SL rispetto all'intero stack .NET sono animali completamente diversi.

— Aaron McIver,

Sì, ma poiché puoi già fare cose come OOB come suggerisci con SL, perché non portare il resto (1/3? 40%?) Dello stack .NET? O SL non è altro che un tentativo di uccidere Flash?

— Ðаn

@Dan Quando le aziende stanno spingendo le cose nel cloud ... l'ultima cosa che vuoi fare è portare uno stack sopra che non può funzionare nel cloud. SL può funzionare su tutti i browser. Puoi discutere con artisti del calibro di Google e altri: la spinta a lavorare all'interno di un browser è reale. Perché in questo momento sceglieresti di trasferire un intero stack su un sistema operativo con una quota di mercato <10% insieme alla virtualizzazione così diffusa ai nostri giorni?

— Aaron McIver,

Microsoft (probabilmente) ha il miglior ambiente di sviluppo disponibile oggi con C # e .NET. Ma aziende come la mia si allontaneranno sempre più da esso a causa dell'incertezza che circonda il Mac / iPad / cloud / ecc. Il C ++ sembra molto più sicuro.

— Ð

3

Gran parte del profitto di Microsoft deriva da due prodotti: Windows e Office. La compatibilità multipiattaforma danneggerebbe Windows.

Se vuoi davvero lo stesso codice in esecuzione su più piattaforme, scrivi un'app Web. Non sembra come te, però. "Per ogni evenienza" non è una buona ragione, è un creep.

Anche se decidi di scegliere come target Mac OS X o iOS tra 16 mesi, pensi davvero di poter prendere il tuo codice C ++ esistente e trasformarlo in una buona (o addirittura funzionale) app nativa? A meno che tu non stia lavorando a un gioco a schermo intero, la risposta è no.

Risparmia tempo con C # ora e, se decidi di passare al Mac, riscrivilo in modo Mac con Objective-C e Cocoa: i tuoi utenti ti ringrazieranno.

— Tobias Cohen
fonte

1

"Just in case" è la realtà; nessuno vuole dire al management "oops" quando c'è un'opzione più sicura in C ++.

— Ð

1

Supponendo che il codice dell'interfaccia sia correttamente separato, sarà più semplice spostare il codice C ++ sul Mac. Riscrivi l'interfaccia in Objective-C usando Cocoa, collega il resto e hai svolto gran parte del lavoro.

— David Thornley,

@ David: e quindi il problema alla base di questa domanda: più C ++, (molto) meno C #. Mi piace (davvero) C #!

— Ð

Queste preoccupazioni multipiattaforma proprio qui è il motivo per cui molti di noi usano ancora Java e non si spostano su C #.

— Brian Knoblauch,

1

c'è una risposta semi-autorevole al perché Microsoft non supporta .NET sul Mac stesso?

Dov'è il mercato che giustificherebbe gli Stati Uniti a spendere il tesoro codificandolo? Per fare questo, avrebbero dovuto buttare via un sacco di soldi - milioni di dollari di stipendio. Un processo in corso, man mano che arrivano correzioni e aggiornamenti.

E per cosa? Vantarsi dei diritti? Tutto ciò che ne ricavano è la possibilità per le persone di abbandonare Windows per Apple ed essere ancora in grado di eseguire le loro app.

Se qualcuno trarrebbe profitto da ciò, sarebbe Apple. Semplifica il passaggio delle persone alla loro piattaforma e agli sviluppatori (SVILUPPATORI) di codificarlo. Ma pensi che SJ se ne frega? Preferiscono inventano cose nuove a bastone un i Infront. Inoltre, la maggior parte del framework è OS e le specifiche CLR sono gratuite per chiunque. Non puoi attaccare una sporca NDA su nessuna di esse.

— Derubati
fonte

Parte di "cosa c'è dentro per Microsoft" è mantenere le persone che usano i loro strumenti di prim'ordine su Windows. Il modo in cui vanno le cose qui, C # /. NET verrà relegato in app interne. Gli sviluppatori che usano C # da anni scrivono di nuovo C ++. Per quanto riguarda il costo; sembra che siano già circa 2/3 lì con Silverlight e / o Mono.

— Ð

Mono è una piattaforma open source e mentre il sorgente per .NET è stato rilasciato, .NET Framework NON è open source. Microsoft non sarà in grado di acquistare Mono, per molte ragioni, la principale è che non hanno un'unica applicazione open source al 100%. Sai che Silverlight è solo una lingua in .NET e il motivo per cui è multipiattaforma perché Microsoft vorrebbe che fosse un sostituto di Flash. Vorrei anche aggiungere che Apple ha fatto dei movimenti delle mani per non permettere nemmeno qualcosa del genere sul loro sistema operativo.

— Ramhound,

1

@Dan sembra che la soluzione ai tuoi guai non sia "una lingua per dominarli tutti", ma "Come implementare in modo indipendente dalla piattaforma". La maggior parte delle persone lo sta realizzando interrompendo l'interfaccia utente dalla logica, incorporandone una per piattaforma e l'altra come servizio sugli innertubi.

— Strappato il

1

@Dan Ho una soluzione per questo ... Non programmare per Mac. Ho un Accordo personale non sviluppato per Apple che ho scritto e firmato da solo. Odierei assolutamente non poter codificare C #, e quindi evitare di farlo. Ma a volte devi fare quello che devi fare, e se i desideri fossero pesci dovremmo pensare a qualche altra allitterazione per descrivere le molte cose che vogliamo ma che non possiamo avere.

— Strappato il

1

@Dan kindasorta. Non hanno ancora toccato il desktop (ancora). Ma sono stupito di quale differenza faccia cinque anni.

— Strappato il

0

Potresti trovare utile il progetto MonoMac: http://www.mono-project.com/MonoMac

Permette lo sviluppo di applicazioni Cocoa Mono style, che possono essere implementate nel Mac App Store.

Considererei fortemente questo approccio per uno sviluppatore che non ha familiarità con Objective-C ma con .NET / Mono / Java che deve fornire un'applicazione in uno scenario limitato nel tempo.

0

Nessuna.

Ti consiglio di scrivere un'applicazione C ++ cross-compilable - potresti provare gioia - o di usare Ruby con wxWidgets.

Considero .NET una cattiva proposta per lo sviluppo multipiattaforma e la manutenzione a lungo termine del prodotto. Anche se, amico, puoi svelare velocemente le app. : - /

Vorrei che Delphi fosse ancora un grande contendente.

— Paul Nathan
fonte

1

Hai mai sentito parlare di Lazzaro?

— Happy Coder,

Inoltre, mai capo di Java?

— Fernando Gonzalez Sanchez,

0

Se si desidera eseguire .NET in modo nativo su un Mac, è possibile utilizzare BootCamp per fare ciò (ovvero eseguire Windows su Mac e le applicazioni .NET in Windows).

Se intendevi Mac OS X anziché solo l'hardware, puoi utilizzare VMWare o Parallels per eseguire le applicazioni .NET in Windows (in emulazione) in OS X. Entrambe hanno modalità visive che consentono all'applicazione di apparire come se fosse in esecuzione solo all'interno di OS X (sembrerà e si comporterà come un'applicazione Windows, ma se stai scrivendo un'applicazione non web multipiattaforma senza un'interfaccia personalizzata per ciascun sistema operativo avrai sempre quel problema).

In questo modo otterrai lo stesso "supporto", poiché stai eseguendo l'app in Windows, sebbene virtualizzata. Ovviamente, chiunque esegua l'app avrà bisogno di una copia del software di virtualizzazione e di Windows e sarà disposto a sopportare un'app che non si comporta come un'app per OS X - ma è l'unico modo per avere "nativi" .NET in esecuzione su un Mac.

— Tony Meyer
fonte

0

Dan, non penso che tu possa farlo. Tuttavia, una possibile soluzione (ancora vapourware) è utilizzare Embarcadero Rad Studio C ++ Builder, che ha un buon VCL per lo sviluppo di applicazioni visive (su cui si basa gran parte di .net) e sono RUMORATI per avere supporto multipiattaforma in uscita nella prossima versione.

Questo sarà sviluppato su Windows, destinato a Mac o Linux. O almeno così dice la loro tabella di marcia.

L'ambiente C ++ è ragionevole e se si sviluppa contro il VCL, in teoria l'applicazione funzionerà solo su altre piattaforme.

Naturalmente fino a quando non viene effettivamente spedito resta da vedere quanto sia davvero efficace.

— quickly_now
fonte

-2

La risposta è no.

In realtà il tuo caso sembra essere un ottimo esempio di quando non scegliere .NET.

— Gabriel Magana
fonte

Nessuno può prevedere il futuro e nessuno vuole correre rischi "indebiti".

— Ð

@Dan: E il punto è? Sembra che tu sia d'accordo con me ...?

— Gabriel Magana,

-3

Se si desidera sviluppare per un sistema operativo, utilizzare gli strumenti giusti. Non ci sono app veramente professionali scritte in mono per Mac. D'altra parte ci sono molti sviluppatori non professionisti che usano molti strumenti per creare molta spazzatura. Guarda le recensioni delle app mono che sono state scritte per OSX. Gli sviluppatori scrivono usando un framework incompleto hackerato per abbinare la piattaforma OSX. Inizia a scrivere: se hai utilizzato C #, l'obiettivo C è un apprendimento rapido.

Gli sviluppatori professionisti per Mac usano C ++, Objective C, Cocoa e Xcode. Sviluppo su diverse piattaforme e ognuna ha i propri strumenti migliori. Usa Xcode per Mac e iOS.

Proprio come una nota a margine Xcode non è Visual Studio, non è così stabile ed è una vergogna per Apple in confronto, ma funziona bene quando ci si abitua alle sue stranezze. È molto difficile battere gli strumenti di Microsoft - ma sono stati scritti per Windows non Linux, iOS, OSX, AIX ecc.

— Dr. Maynord
fonte

1

Hai dei fatti per il backup di dichiarazioni come "Xcode non è così stabile ed è una vergogna per Apple" perché in base alla mia esperienza personale tutti quelli che hanno usato Xcode lo hanno adorato. Inoltre, anche dopo aver espresso la tua opinione personale su un argomento che sembra non essere familiare, non sei nemmeno consapevole del fatto che nel 2013 esiste effettivamente una soluzione. Naturalmente la soluzione è in realtà Monoe Xamarin.Macma è una soluzione. L'attuale versione di Mono è quasi un'implementazione completa al 100% di .NET 4.0, manca solo di un paio di funzionalità principali che probabilmente non verranno mai portate (ad es. WPF).

— Ramhound,