Il caso a favore o contro .NET (la bestia) [chiuso]

L'azienda per cui lavoro utilizza C ++ Builder 6. Abbiamo sviluppato codice nativo sin dal concepimento. Il nostro prodotto di punta è scritto completamente in codice nativo.

Entra in .NET Framework con i suoi campanelli e fischietti. Cado, gancio, lenza e piombino. Convinco il management che .NET dovrebbe assolutamente essere il nostro nuovo framework per tutto lo sviluppo di nuovi software e che dovremmo iniziare a migrare la nostra codeline esistente al più presto. Con tutti i vantaggi non ci vuole molto per convincere. Accettano la mia proposta come al solito.

A questo punto inizio a sviluppare la mia prima applicazione .NET. Sta andando tutto come previsto. Il progetto è solo una componente del nostro prodotto. E così arrivo al punto di creare un programma di installazione per questo nuovo componente. Come azienda, siamo orgogliosi di rendere le cose per l'utente il più semplici possibile. Anche Microsoft con migliaia di sviluppatori non crea programmi di installazione come noi. Quando installi Microsoft CRM, ad esempio, otterrai solo un elenco di errori e prerequisiti che devono essere installati prima di poter continuare. Non noi. Mai. Se hai bisogno di qualcosa, lo installeremo per te.

Questo rende le nostre installazioni così facili. .NET Framework non è installato? Nessun problema! Lo faremo per te. Hai bisogno di un client SQL Native? Bene!

Il problema è questo, ora che un singolo componente della nostra soluzione è scritto in .NET, complica incredibilmente il processo di installazione. Prima ancora di poter installare il nostro prodotto, devo fare quanto segue:

• Rileva se il prerequisito è installato

• Installalo se non lo è

• Verifica che sia stato installato correttamente

• Prerequisito successivo

Per installare .NET Framework, ho bisogno prima di Windows Installer 4.5. Ma ci sono diverse versioni per i diversi sistemi operativi, quindi aggiungo il rilevamento del sistema operativo e lancio l'EXE corretto. Oh, .NET framework è già fornito con 2k8 e l'exe di installazione non può essere eseguito su di esso, devi eseguire OCSetup.exe con i parametri per installarlo.

E così va avanti. Quindi è necessario installare SQL Express 2005. Le dipendenze aumentano ancora una volta.

Sostengo con la direzione che anche Microsoft non lo rende così facile per l'utente. La loro risposta è che non c'è motivo per noi di non essere migliori di loro in questo modo. Non posso discuterne, tranne che ritengo che ci siano ottime ragioni per cui hanno scelto il loro approccio.

All'improvviso, il nostro programma di installazione è enorme. Tutti i prerequisiti per .NET, nemmeno parlando del supporto a 64 bit che ha un'intera gamma separata di EXE da installare. Quindi ora si arriva al punto in cui vogliamo che gli utenti siano in grado di scaricare una valutazione "rapida". Che scherzo. È necessario scaricare 500 MB per eseguire un'applicazione da 30 MB. La maggior parte del pacchetto di installazione è costituita da prerequisiti.

La direzione ritiene che abbiamo troppe dipendenze / prerequisiti. Capisco perfettamente. Suggeriscono di allontanarci dal framework .NET, tornando alla terra natia dove le cose erano ancora "facili" in termini di installazione. È qui che l'unica parte di me vuole difendere .NET spiegando i vantaggi nel quadro generale, l'esperienza di sviluppo migliorata, la manutenzione più semplice e la qualità complessiva del codice. L'altra parte di me è d'accordo con loro di tutto cuore! Lo sviluppo in .NET richiede semplicemente l'installazione di troppi altri prerequisiti che complicano l'installazione.

Sì, alcuni dei sostenitori di .NET affermeranno che tutto dovrebbe essere installato su un sistema operativo aggiornato e aggiornato. Questo è vero, ma non tutti i clienti lo hanno e semplicemente dicendo "Mi dispiace, aggiorna prima" semplicemente non lo taglierà. Ricorda, siamo orgogliosi dell'esperienza utente complessiva.

Stiamo ora valutando la possibilità di scrivere di nuovo codice nativo e so che stiamo perdendo in termini di velocità di sviluppo e tutte le chicche di .NET. Ma stiamo guadagnando in quest'area, sia essa piccola se guardi al quadro generale o no. Poiché abbiamo capacità di sviluppo di codice nativo e .NET è in realtà un nuovo terreno per noi, ha senso anche tornare indietro.

La mia domanda è questa: qual è il punto di vista della tua azienda su questo problema se si tratta di un problema e quale sarà il caso aziendale che propongo al management supponendo che voglia continuare a migrare tutti i nostri prodotti a .NET?

Questo è il motivo per cui molte aziende sono passate a programmi di installazione web che scaricano tutti i prerequisiti al volo dalla tua home page. Poiché nella maggior parte dei casi, il sistema operativo ha il 99% di ciò che è necessario (se è stato aggiornato tramite Windows Update).

Non metterei tutto per x64 e x32 nello stesso programma di installazione. Crea due programmi di installazione, uno per ciascuna architettura.

Paint.NET avvolge l'installazione dei prerequisiti senza raggruppare il framework .NET con esso per impostazione predefinita. Il risultato finale è un eseguibile shim non gestito che controlla il framework .NET e altre cose e ti tiene per mano quando viene installato; tutti scaricati al volo quando servono. Quindi eseguono un'applicazione WinForms che invoca in MSI per avvolgere ulteriormente l'installazione in ovatta.

Vale un Google.

È anche probabile che su molte macchine client sia già installata una versione di .NET Framework in quanto fa parte di Microsoft Update, rendendolo più facilmente utilizzabile nel mondo degli affari.

Post del blog Paint.NET sull'installazione:

http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/

http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (grazie Rup!)

Leggendo un po 'di più la storia, presumibilmente il management ha dovuto affrontare il problema della distribuzione con l'applicazione C ++ almeno una volta, ma ora è fatto e classificato come "facile". Metti un po 'di tempo contro la distribuzione e presentalo alla direzione e, nascondendo il dolore, mostra loro quanto sia facile da installare :)

Torniamo al motivo per cui hai voluto passare dal codice nativo al codice .NET in primo luogo: è più efficiente per te, come programmatore. Molte cose sono più facili in .NET che in C ++ (o in qualsiasi lingua nativa tu stia utilizzando), quindi puoi sviluppare le tue applicazioni molto più rapidamente.

Quindi, come si confronta il tempo che dedichi allo sviluppo dell'applicazione rispetto al tempo che dedichi allo sviluppo del programma di installazione? Anche se devi passare un paio di settimane a inchiodare l'installatore (in particolare la parte di configurazione del framework), quella dovrebbe essere più o meno l' unica volta che hai a disposizione.

Per tutte le applicazioni future, userete un programma di installazione quasi identico; faresti comunque tutti i controlli dei prerequisiti, ma invece di copiare i file in C: \ Foo, stai copiando alcuni file diversi in C: \ bar.

A mio parere, questa è una semplice questione di economia. Sì, è più costoso sviluppare un programma di installazione (buono / completo) per un'applicazione .NET, ma se questo è il passaggio che devi compiere una volta per migliorare notevolmente il tempo di sviluppo, è un gioco da ragazzi. Il tuo ritorno sull'investimento sarebbe probabilmente dell'ordine di settimane.

Sento di dover rispondere a questa affermazione:

Sì, alcuni dei sostenitori di .NET affermeranno che tutto dovrebbe essere installato su un sistema operativo aggiornato e aggiornato. Questo è vero, ma non tutti i clienti lo hanno e semplicemente dicendo "Mi dispiace, aggiorna prima" semplicemente non lo taglierà. Ricorda, siamo orgogliosi dell'esperienza utente complessiva.

Se il tuo utente insiste a spararsi ai piedi azionando un sistema che il fornitore ha informato che non è più adatto allo scopo , allora non puoi fare molto per "aiutarlo". Sono consapevole che questo mi fa sembrare una specie di attivista odioso, ma lo vedo nello stesso modo in cui potrebbe farlo un commerciante manuale: spetta al cliente assicurarsi che l'ambiente in cui vuole che lavori sia sano e appropriato per il prodotto. In caso contrario, accetterò ulteriori rinumerazioni per fare anche quel lavoro, ma potrebbe comunque causare loro un lavoro extra perché non hanno avuto la lungimiranza di assicurarsi di aver capito cosa stavano acquistando.

Credo che ai clienti di software sia stato permesso di rimanere ignoranti per un tempo sufficientemente lungo e che ora dovrebbe essere loro richiesto di capire cosa stanno acquistando. Gestire un ambiente IT aziendale che non è adeguatamente patchato equivale a continuare a guidare un veicolo che è stato oggetto di un richiamo del produttore: un service pack di Windows è equivalente a un richiamo sotto molti aspetti. Non sei legalmente obbligato a presentare un richiamo, ma è nel tuo interesse come azienda e potresti essere ritenuto responsabile per i danni causati dalla tua sottrazione di responsabilità.

Qualsiasi app Visual C ++ ha anche prerequisiti / dipendenze esterne: runtime 6.0, 2003, 2005, 2008 o 2010? niente SP, SP1 o SP2? x86 o x64? Quale versione di Windows Installer richiede 2005 SP2? E cosa 2008 SP1? E così via, così via.

Quindi sono argomenti inverosimili! Come le lamentele di Joel su .NET. E guarda cosa c'è adesso !

Non vedo come ci siano molti più prerequisiti per .net su C ++ Builder. Ti lamenti di SQL Server, ma ignori il fatto che devi installare anche alcuni database con C ++ builder. Ti lamenti di x64 rispetto a x32, ma .NET non richiede alcuna modifica .. lo stesso exe viene eseguito su entrambi (e si compila in modo ottimale per entrambi gli ambienti). Lo stesso non si può dire di C ++ Builder. Potresti aver bisogno di versioni separate di SQL Server, ma ancora una volta ciò si applicherebbe a C ++ builder (a meno che tu non installi solo x32 su tutto).

Sì, ci sono i problemi della nuova versione del programma di installazione, ma quei componenti non sono molto grandi. E puoi davvero convincere i programmi di installazione a scaricare e installare solo gli aprts necessari.

Il builder C ++ è probabilmente più facile per te perché hai già investito il tempo nella creazione di un buon programma di installazione. Devi fare lo stesso per .NET, quindi puoi scegliere in base a problemi reali .. e non questo.

A proposito, il motivo per cui Microsoft sceglie di fare le cose nel modo in cui lo fa è che molti utenti, in particolare gli utenti aziendali, non apprezzano che le cose vengano installate automaticamente (forse perché hanno un'applicazione che dipende da una versione specifica di una libreria, e tu vieni e lo cancelli con una nuova versione che non possono disinstallare facilmente).

Ciò che consideri "rendere tutto più facile" per le persone meno informate in realtà sta rendendo le cose MOLTO più difficili per coloro che sanno cosa stanno facendo.

Ecco un buon esempio. Una cosa che disprezzo assolutamente è quando installo un'app che richiede SQL Server e installa la propria istanza di SQL Server, anche se potrei già avere diverse istanze che potrebbe utilizzare. Facile per i principianti, un rompicoglioni per me provare a far funzionare la tua app con la mia singola istanza.

Se l'app viene eseguita in Mono, la spedizione dell'app con il runtime Mono potrebbe essere meno complicata.