O caso a favor ou contra .NET (a besta) [encerrado]


92

A empresa para a qual trabalho usa C ++ Builder 6. Temos desenvolvido código nativo desde a concepção. Nosso principal produto é escrito totalmente em código nativo.

Entra no .NET Framework com seus sinos e assobios. Eu caio, gancho, linha e chumbada. Eu convenço a gerência de que .NET deve ser absolutamente nossa nova estrutura para todo o desenvolvimento de software e que devemos começar a migrar nossa linha de código existente o mais rápido possível. Com todos os benefícios, não é preciso muito para ser convincente. Eles aceitam minha proposta como de costume.

Nesse ponto, começo a desenvolver meu primeiro aplicativo .NET. Está tudo indo como planejado. O projeto é apenas um componente do nosso produto. E assim chego ao ponto de criar um instalador para este novo componente. Como empresa, temos orgulho de tornar as coisas para o usuário o mais fáceis possível. Mesmo a Microsoft com milhares de desenvolvedores não cria instaladores como nós. Ao instalar o Microsoft CRM, por exemplo, você obterá apenas uma lista de falhas e pré-requisitos que precisam ser instalados antes de continuar. Nós não. Nunca. Se você precisar de algo, nós o instalaremos para você.

Isso torna nossas instalações tão fáceis. .NET Framework não está instalado? Sem problemas! Faremos isso por você. Precisa de um cliente SQL Native? Bem!

O problema é este, agora que um único componente da nossa solução foi escrito em .NET, ele complica incrivelmente o processo de instalação. Antes mesmo de instalar nosso produto, preciso fazer o seguinte:

  • Detecte se o pré-requisito está instalado

  • Instale se não for

  • Verifique se foi instalado com sucesso

  • Próximo pré-requisito

Para instalar o .NET Framework, preciso primeiro do Windows Installer 4.5. Mas existem versões diferentes para os diferentes sistemas operacionais, então adiciono a detecção de sistema operacional e inicio o EXE correto. Oh, o .NET framework já vem com 2k8 e o instalador exe não pode ser executado nele, você tem que executar OCSetup.exe com parâmetros para instalá-lo.

E assim continua. Em seguida, o SQL Express 2005 precisa ser instalado. As dependências aumentam mais uma vez.

Eu defendo com a gerência que nem mesmo a Microsoft torna isso fácil para o usuário. A resposta deles é que não há razão para não sermos melhores do que eles dessa forma. Não posso contestar isso, exceto que sinto que há boas razões para eles seguirem sua abordagem.

De repente, nosso instalador é enorme. Todos os pré-requisitos para .NET, sem falar no suporte a 64 bits, que tem toda uma gama separada de EXEs para instalar. Portanto, agora chegamos ao ponto em que queremos que os usuários possam fazer o download de uma avaliação "rápida". Que piada. Você precisa baixar 500 MB para ter um aplicativo de 30 MB em execução. A maior parte do pacote de instalação é pré-requisitos.

A gerência sente que temos muitas dependências / pré-requisitos. Eu entendo completamente. Eles sugerem que nos afastemos do framework .NET, de volta à terra natal, onde as coisas ainda eram "fáceis" em termos de instalação. É aqui que uma parte de mim quer defender o .NET, explicando os benefícios em geral, a experiência de desenvolvimento aprimorada, a manutenção mais fácil e a qualidade geral do código. A outra parte de mim concorda com eles de todo o coração! O desenvolvimento em .NET requer apenas a instalação de muitos outros pré-requisitos, o que complica a instalação.

Sim, alguns dos defensores do .NET afirmam que tudo deve ser instalado em um sistema operacional corrigido e atualizado. Isso é verdade, mas nem todos os clientes têm isso, e simplesmente dizer "Sinto muito, atualize primeiro" não é suficiente. Lembre-se, temos orgulho da experiência geral do usuário.

Agora estamos considerando escrever código nativo novamente e sei que estamos perdendo em termos de velocidade de desenvolvimento e todas as vantagens do .NET. Mas estamos ganhando nesta área, seja pequeno se você olhar para o quadro geral ou não. Como temos habilidades nativas de desenvolvimento de código e o .NET é realmente um terreno novo para nós, faz sentido voltar para trás.

Minha pergunta é a seguinte: qual é a visão da sua empresa sobre esse problema, se é que é mesmo um problema, e como será o business case que proponho à administração, supondo que quero continuar migrando todos os nossos produtos para .NET?


23
1 para uma linda história.
jgauffin

25
Não existem instaladores stub para .net que baixam componentes conforme necessário? Juntar os instaladores completos é ideal para um lançamento em DVD, mas se eles baixaram uma avaliação, você pode presumir que eles estão online para uma instalação online de .net.
Rup

4
Ironicamente, alguns dos livros sobre .NET que aprendi durante meus dias de faculdade mencionaram a implantação do XCOPY como um de seus principais benefícios :)
Madhur Ahuja

25
Você se esqueceu de incluir sua dependência do Windows. Isso é outro par de gigabytes. Use os bootstrappers.
Hans Passant

13
Uma história interessante deve ter o título "Como NÃO mudar a forma como toda a sua empresa faz negócios com base na leitura de alguns materiais de marketing e antes de aprender o que você realmente precisa fazer para usar a nova estrutura corretamente"
Andrew Barber

Respostas:


50

Esta é a razão pela qual muitas empresas mudaram para instaladores da web que baixam todos os pré-requisitos rapidamente de sua página inicial. Já que na maioria dos casos, o SO tem 99% do que é necessário (se eles foram atualizados usando o Windows Update).

Eu não colocaria tudo para x64 e x32 no mesmo instalador. Crie dois instaladores, um para cada arquitetura.


2
Não acredito que você possa obter os pacotes de instalação x64 e x86 em um único banco de dados MSI.
David Heffernan

Verdade. Acabei de responder aSuddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole seperate range of EXEs to install
jgauffin

6
QUALQUER software requer instaladores x86 e x64 separados!
Choramingando

4
abatishchev: Se o software fosse apenas um binário .NET compilado para a arquitetura "Any", não haveria necessidade de instalações x86 e x64 separadas. É apenas quando você tem que instalar o próprio .NET framework que você precisa de instaladores separados.
Gabe

Se você escrever um instalador web, lembre-se das pessoas que vivem atrás de proxies. Mesmo a Microsoft frequentemente falha em lembrar sobre as pessoas que vivem atrás de seu próprio ISA (estou olhando para o seu instalador Web Developer).
Egor Pavlikhin

39

O Paint.NET encerra a instalação de pré-requisitos muito bem sem agrupar o .NET framework com ele por padrão. O resultado final é um executável shim não gerenciado que verifica a existência do .NET framework e outras coisas e segura sua mão enquanto é instalado; todos baixados na hora, conforme necessário. Em seguida, eles executam um aplicativo WinForms que inicia no MSI para encerrar a instalação em algodão.

Vale a pena Google.

Provavelmente também é o fato de que muitas máquinas clientes já terão alguma versão do .NET Framework instalada, pois faz parte do Microsoft Update - tornando-o mais facilmente consumível no mundo dos negócios.

Postagens do blog Paint.NET sobre a instalação:

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/ (obrigado Rup!)

Lendo um pouco mais a história, presumivelmente o gerenciamento teve que passar pela dor da implantação com o aplicativo C ++ pelo menos uma vez, mas agora está feito e classificado como "fácil". Dedique algum tempo à implantação e apresente isso ao gerenciamento e, escondendo a dor, mostre a eles como é fácil instalar :)


Obrigado pelo link. A segunda parte é blog.getpaint.net/2008/08/25/… (não consegui ver um link da primeira na página, embora esteja realmente lá nos cabeçalhos)
Rup

@Rup nice find! Eu dei uma olhada rápida e não percebi. Vou corrigir minha resposta para mostrar isso.
Adam Houldsworth

Eu me pergunto se existe um instalador de código aberto semelhante ao 4.0 para Paint.net. Seria extremamente útil para qualquer pessoa que distribua aplicativos .net.
dbkk

1
@dbkk você está me dizendo! O Paint.NET costumava liberar o código do programa e do instalador, mas desde então foi cancelado devido a programas copy-cat que não davam crédito ao autor.
Adam Houldsworth

1
Se você instalar / atualizar o Paint.NET com o Visual Studio aberto, ele pode corromper o Visual Studio. Eu diria que o instalador ainda precisa de algum trabalho.
Greg

37

Vamos voltar ao motivo de você querer mudar do código nativo para o código .NET em primeiro lugar: é mais eficiente para você, como programador. Muitas coisas são mais fáceis em .NET do que em C ++ (ou em qualquer linguagem nativa que você esteja usando) e, portanto, você pode desenvolver seus aplicativos muito mais rapidamente.

Então, como o tempo que você gasta desenvolvendo o aplicativo se compara ao tempo que você gasta desenvolvendo o instalador? Mesmo que você tenha que passar algumas semanas instalando o instalador (especificamente a parte de configuração do framework), esse deve ser mais ou menos o único tempo que você tem para passar por isso.

Para todos os aplicativos futuros, você usaria um instalador quase idêntico; você ainda faria todas as verificações de pré-requisito, mas em vez de copiar arquivos para C: \ Foo, você está copiando alguns arquivos diferentes para C: \ bar.

Na minha opinião, esta é uma questão simples de economia. Sim, é mais caro desenvolver um instalador (bom / completo) para um aplicativo .NET, mas se essa é a etapa que você precisa realizar uma vez para melhorar drasticamente o seu tempo de desenvolvimento, é um acéfalo. O retorno do investimento seria provavelmente da ordem de algumas semanas.


1
+1, uma boa experiência de instalação em .NET é difícil de definir, mas como você diz, deve ser apenas uma vez. O benefício de ter a maior parte do material clichê de que você precisará ser um System.Something.Class afastado é quase impagável e vale uma ou duas dores de cabeça induzidas pelo instalador.
Adam Houldsworth

2
Estou ansioso pelo lançamento do Wix Burn , o então primeiro bootstrapper que realmente funciona (espero). DotNetInstaller junto com NSIS é o que estou usando atualmente. Mas a manipulação do UAC ainda está longe de ser perfeita.
Uwe Keim

1
@Uwe Parece que Wix Burn será lançado na mesma época que Duke Nukem Forever .
dbkk

Isso seria bom. Eu já vi uma prévia das capturas de tela do Duke Nukem Forever . Então, logo deve estar lá ;-)
Uwe Keim

17

Sinto que preciso responder a esta declaração:

Sim, alguns dos defensores do .NET afirmam que tudo deve ser instalado em um sistema operacional corrigido e atualizado. Isso é verdade, mas nem todos os clientes têm isso, e simplesmente dizer "Sinto muito, atualize primeiro" não é suficiente. Lembre-se, temos orgulho da experiência geral do usuário.

Se o seu usuário insiste em dar um tiro no próprio pé operando um sistema que o fornecedor informou que não é mais adequado , então não há muito que você possa fazer para "ajudá-lo". Estou ciente de que isso me faz parecer uma espécie de ativista desagradável, mas vejo isso da mesma forma que um comerciante manual faria - cabe ao cliente garantir que o ambiente no qual eles querem que eu trabalhe é som e apropriado para o produto. Se não for, aceitarei mais renumeração para fazer esse trabalho também, mas ainda pode causar trabalho extra, porque eles não tiveram a previsão de ter certeza de que entenderam o que estavam comprando.

Acredito que os clientes de software puderam permanecer ignorantes por tempo suficiente e que agora eles deveriam ser obrigados a entender o que estão comprando. Operar um ambiente de TI corporativo que não foi devidamente corrigido é o mesmo que continuar a operar um veículo que foi sujeito a recall do fabricante - um service pack do Windows é equivalente a um recall em muitos aspectos. Você não é legalmente obrigado a submeter-se a um recall, mas é do seu interesse como empresa e você pode ser responsabilizado por danos causados ​​por sua omissão de responsabilidade.


2
Eu diria que o recall do fabricante é um pouco exagerado em termos de analogia - eu diria, é mais como dirigir um carro anterior aos airbags ou ABS - novos recursos surgiram, melhorando a qualidade e aumentando a barra de qualidade. Coisas antigas não se tornam repentinamente quebradas ou perigosas, agora são apenas aceitas como estando abaixo da barra nos padrões de hoje, tenho certeza que a equipe do Windows 95 diria que, na época, eles pensaram que a barra era muito alta! :-) Ainda concordo com você, a ignorância da progressão da qualidade não é uma virtude.
Adam Houldsworth

11
Eu discordo 100%. Os clientes foram obrigados a ter muito conhecimento por muito tempo. Por que eu deveria saber se sou x86 ou x64? Por que devo saber qual service pack estou executando? Deixe-me comprar seu software e você descobrirá o que precisa acontecer para que ele funcione. O software de consumo está inexoravelmente se movendo em direção a um modelo iOS / Android / AppStore e qualquer desenvolvedor que exija que os usuários saibam qualquer coisa além dos detalhes mais básicos sobre seu dispositivo será deixado para trás.
kubi

1
@kubi é claro que a analogia do iOS vem com a suposição de que o hardware não muda porque é controlado pelo fornecedor. Os PCs são totalmente configuráveis, portanto, é necessário algum conhecimento ou consciência dos requisitos - ou, pelo menos, consciência da necessidade de alguém que saiba o que está fazendo. Eu sei o tamanho dos meus pneus ou dou meu carro para alguém que sabe se vou trocá-los.
Adam Houldsworth

3
@kubi: Concordo com você no modelo de usuário casual - a diferença aqui é que não há razão para o usuário não ter delegado todos os problemas técnicos, como versão da plataforma, i) ao fabricante ou ii) a mim, como desenvolvedor. Portanto, eles não são um problema. O usuário que é um problema é o usuário corporativo que não necessariamente tem uma palavra a dizer sobre sua configuração e que deve ter um provedor de TI competente pago para resolver esses problemas.
Tom W

4
Os usuários não ligam para nenhum dos nossos argumentos, por mais sólidos que sejam. Eles querem usar o seu software ... mas podem desistir se a instalação for muito difícil. Eles poderiam se importar menos com quem é a culpa - da Microsoft, dos fornecedores ou deles próprios.
dbkk

7

Qualquer aplicativo Visual C ++ tem pré-requisitos / dependências externas também: tempo de execução 6.0, 2003, 2005, 2008 ou 2010? sem SP, SP1 ou SP2? x86 ou x64? Qual versão do Windows Installer o 2005 SP2 requer? E o que SP1 2008? E assim por diante.

Portanto, são argumentos rebuscados! Como as reclamações de Joel sobre .NET. E olha o que é agora !


3
+1 para vincular ao site de Joel
Security Hound

-1 para vincular ao site do Joels.
Phill

Você pode vincular estaticamente ao tempo de execução para que não precise dessas dependências.
Tony Edgecombe

1
@ Tony: Vinculando estaticamente nos anos 10 do século 21? Absolute mauvais ton ;)
abatishchev

+1 para vincular ao site de Joel
Shahid M Zubair

3

Não vejo como existem significativamente mais pré-requisitos para .net em vez de C ++ Builder. Você reclama do SQL Server, mas ignora o fato de que também precisa instalar algum banco de dados com o construtor C ++. Você reclama sobre x64 vs x32, mas .NET não requer nenhuma mudança .. o mesmo exe roda em ambos (e se compila de forma otimizada para qualquer ambiente). O mesmo não pode ser dito sobre o C ++ Builder. Você pode precisar de versões separadas do servidor SQL, mas, novamente, isso se aplicaria ao construtor C ++ (a menos que você apenas instale o x32 em tudo).

Sim, existem os novos problemas de versão do instalador, mas esses componentes não são muito grandes. E você realmente pode fazer com que os instaladores baixem e instalem apenas os aprts necessários.

O construtor C ++ é provavelmente mais fácil para você porque você já investiu tempo na criação de um bom instalador. Você precisa fazer o mesmo para .NET, e então você pode escolher com base em problemas reais ... e não isso.

A propósito, a razão pela qual a Microsoft opta por fazer as coisas da maneira que fazem é que muitos usuários, especialmente usuários corporativos, não gostam de ter coisas instaladas para eles automaticamente (talvez porque eles tenham um aplicativo que depende de uma versão específica de uma biblioteca, e você chega e o apaga com uma nova versão que eles não podem desinstalar facilmente).

O que você vê como "tornar as coisas mais fáceis" para pessoas com menos conhecimento é, na verdade, tornar as coisas MUITO mais difíceis para aqueles que sabem o que estão fazendo.

Aqui está um bom exemplo. Uma coisa que eu absolutamente desprezo é quando instalo um aplicativo que precisa do SQL Server e ele instala sua própria instância do SQL Server, embora eu já possa ter várias instâncias que ele possa usar. Fácil para o novato, um pé no saco para mim tentar fazer seu aplicativo funcionar com minha única instância.


1

Se o seu aplicativo for executado no Mono, enviar seu aplicativo com o tempo de execução Mono pode ser menos trabalhoso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.