Migrando uma aplicação Delphi 7 para .NET

Question

Qualquer conselhos sobre como migrar um Delphi aplicação 7 negócio existente para .NET 2.0 no Visual Studio 2005?

Visual Studio 2005 já foi comprado, a empresa quer afastar-se das ferramentas Borland / CodeGear.

A aplicação é um único executável do servidor do cliente, utilizando uma série de controles 3rd party UI e Crystal Reports 10 para relatar.

Há uma extensa disseminação lógica de negócios em todos os tipos de Delphi na interface do usuário, bem como procedimentos armazenados muitos SQL Server 2000. Movendo-se muito da lógica proc armazenados em classes .NET é outro gol.

Para reduzir o impacto sobre os clientes, um pedaço por pedaço abordagem ao invés de uma re-gravação / conversão completa seria preferível, se possível. Agradecemos antecipadamente.

[Update] Alguém já teve alguma experiência, bom, mau ou feio, usando Managed VCL para este tipo de cenário?

Answer 1

Eu trabalhava em uma empresa que estava migrando do Delphi para WPF / .Net circa 2007. Nós tentamos uma peça de abordagem peça. Foi doloroso. Estávamos sempre correndo para erros sutis na interoperabilidade. Chamando de Delphi para WPF ou WinForms e volta é dolorosa. Se os vários controles de interface do usuário e janelas de sua chamada aplicativo em cada outro lote um, eu acho que você vai experimentar dores de crescimento significativas.

Se você pode pagar para fazer a conversão inteira de uma só vez eu iria para ele. Se não, dividir as partes do seu aplicativo que são stand-alone ou ter o mínimo de interações com o resto do aplicativo.

Eu também sugeriria salto em .Net 2008. Por que você está escolhendo uma tecnologia que é quase 4 anos de idade (VS 2005)? Eu acho que é uma decisão de negócio muito, muito ruim para escolher a saltar para .Net 2.0 quando Net 3.5 é muito estável. A única razão válida que eu faria sempre presente à gerência para .Net 2.0 seria para suportar o Windows 2000. Você ainda tem clientes em Win2k? Será que você ainda tem clientes em Win2k no momento em que sua conversão é completa? Você tem clientes que você não pode começar a se mover para o XP ou Vista? Net 3.0 e 3.5 não são suportados em Win2k. Que é a única desvantagem que posso pensar.

.Net 3.5 e C # 2008 oferecem vantagens significativas para sua empresa. Você tem uma série de recursos de linguagem que vão acelerar o desenvolvimento de tempo em comparação com C # 2.0. Você tem WPF, que é muito superior à WinForms. Eu diria que você pode desenvolver o mesmo Windows batteleship-cinza que você iria ficar em WinForms com WPF, desenvolvê-los mais rápido, e quando você quer um pouco de olho-doce você estará usando uma tecnologia que pode facilmente fornecê-la. Se você está aprendendo uma nova plataforma de janelas para esta conversão, porque não investir em aprender coisas novas?

Além disso, por favor me diga que você não realmente comprar VS 2005. Você pode comprar um licença MSDN Universal para sobre o mesmo custo, e obter cada produto de desenvolvimento relacionado Microsoft faz. Comprá-lo a partir de um terceiro partido e você vai obter um bom desconto.

Desculpe se eu saiu negativo. Sinceramente, boa sorte na migração. Eu só tenho flashbacks quando penso em ter que desistir de todos os presentes na Net 3.5.

Answer 2

Isso soa como um péssima idéia para mim.

Há alguma vantagem tecnológica para o seu produto para a NET, ou é principalmente uma decisão política para ser uma loja de Microsoft? Para cliente-servidor, Delphi é muito difícil de bater. Eu usei VS2005 / 8 e não é realmente e verdadeiramente genuína e sinceramente tão bom quanto Delphi para o desenvolvimento Win32. Mas se você estiver indo para migrar para a web na estrada, então VS tem vantagens concretas.

Se as pessoas de negócios teimosos simplesmente se recusam a usar Delphi mais, então KiwiBastard está correto, IMO. Converter primeiro a Delphi.NET, em seguida, migrar de lá para VS2005. Ou 2010, uma vez que é um cronograma mais realista:)

Answer 3

Eu já trabalhei em uma empresa que queria converter de Delphi para C # .NET porque .NET é tudo arrefecer e brilhante . Eles trouxeram mais alguns desenvolvedores que tiveram um monte de C # experiência e acabou levando 3 vezes os desenvolvedores dobro do tempo para portar o aplicativo para C #, então ele tinha que escrevê-lo pela primeira vez em Delphi para ROI muito pouco adicional (alguns novos recursos foram adicionados no processo). Além disso, os clientes não estavam satisfeitos com o desempenho do aplicativo ou a interface do usuário.

Caso de estudo após estudo mostra casos que reescrita é uma idéia ruim . (Gorjeta de chapéu para kogus )

Se você deve mover-se para .NET (sim, eu sei, você não tomar a decisão, alguém com menos informação se), então eu sugiro usar Delphi para .NET ou RemObjects Oxygene . Sendo este último um Visual Studio plug-in. Mas mesmo marc Hofman, o arquiteto-chefe de software da RemObjects Oxygene disse que é uma má idéia migrar uma aplicação perfeitamente trabalhando para .NET "apenas porque."

Se você pode esperar para Delphi Prism, que também é um Visual Studio add-in e é esperado para ser lançado ainda este ano.

Answer 4

A fragmentada conversão significaria alterar o código Delphi nativa de usar COM para o lado do .NET podem coexistir com Delphi (ou possivelmente usando alguma outra tecnologia - difícil dizer)

Se você pode, talvez seja mais fácil para converter o aplicativo para Delphi.NET primeiro, então pelo menos os bits .NET será capaz de comunicar-se um pouco mais fácil.

Apenas um pensamento.

Answer 5

se afastando da CodeGear / Borland ferramentas basicamente elimina qualquer solução baseada Delphi .NET e uma reescrita total de sua aplicação.

Espero que minha resposta abaixo ajuda com suas decisões.

A partir da experiência (tendo reescrito uma aplicação Delphi com uma equipe de pessoas) que se resume a uma das duas opções abaixo.

Mas primeiro um aviso:. Você vai demorar pelo menos o esforço total de desenvolvimento que levou para escrever o seu aplicativo atual Delphi

No nosso caso, este esforço foi garantido desde o antigo aplicativo Delphi (que na verdade era Kylix) teve um fim-de-vida devido a várias razões. Nossa reescrita consistiu em duas partes:. Reescrita com funcionalidade extra limitado seguido por um monte de funcionalidade extra (o desenho da primeira parte já tomou a segunda parte em consideração)

Voltar para suas escolhas:

1- uma reescrita total na C # ou VB.NET no Visual Studio

2 a reutilização parcial de seu código de camada de negócios Delphi existente usando Oxygene de RemObjecs (um plug-in Visual Studio com uma sintaxe que é muito semelhante à sintaxe Delphi). CodeGear vai oferecer Prism breve (provavelmente antes do final de 2008), que também vai integrar em Visual Studio.

Como o acesso de dados .NET e UI são totalmente diferentes do Delphi, você vai ter que fazer estes a partir do zero (tanto para o cenário 1 e 2). Visual Studio 2008 oferece uma série de benefícios aqui sobre Visual Studio 2005.

Não existe tal coisa como fazendo esta migração gradual, uma vez que você faz uma mudança plataforma completa aqui, é uma abordagem de tudo ou nada.

Ambos os do cenário vai levar uma quantidade considerável de tempo (mesmo que você tenha experiência Delphi, obtendo-se acostumados no mundo do .NET levará tempo).

Visual Studio pode interagir com o Crystal Reports, e vai bem com SQL Server.

Uma vez que Visual ofertas Estúdio 2008 uma série de benefícios (não só .NET 3.5, mas também a produtividade sábio), é melhor você ir com isso. Do lado da interface do usuário, você precisa fazer uma escolha equilibrada entre WinForms (aka Windows Forms) e Windows Presentation Foundation (WPF aka).

Se é uma reescrita 1-to-1, você pode querer ficar com WinForms como é familiar para o que você tem. Você provavelmente precisará usar alguns componentes do 3o partido para obter a sua UI indo; DevExpress é uma boa escolha aqui como eles têm componentes similares em Delphi e Visual Studio.

Mas se você quiser ir para doces futuro olho, então você pode considerar WPF. Esteja preparado para uma curva de aprendizagem mais íngreme do que aqui WinForms, pois é muito diferente do que você está acostumado.

Se você decidir ficar com Delphi, você pode querer olhar para VCL for the Web (aka IntraWeb) e em Delphi 2009 (muita coisa mudou no mundo Delphi desde Delphi 7 foi anunciado há 6 anos).

Boa sorte fazer suas escolhas!

- jeroen

Answer 6

Eu sugeriria olhar Hydra de RemObjects. Ele basicamente bate a interface com para você e fornece um observador padrão para interface entre o aplicativo Delphi e .Net. Você pode ter formas .Net aparecem em painéis dentro do seu aplicativo Delphi. Isto fornece um caminho de migração agradável, onde você substituir o seu bit de código Delphi a pouco como você funcionalidade de migração para .Net.

Answer 7

Para mim, a pergunta seria: que língua você estaria usando? Eu faço esperança C # e VB.Net não. (Com todas as políticas embaraçosas neste usecase isso não está claro por qualquer meio.)

O próximo provavelmente você vai ouvir é que existem conversores lá fora, que irá ajudá-lo a fazer isso. Nós acabou de passar por uma avaliação de tais conversores (Delphi 7 para C #) e foram muito! desapontado.

Posso sugerir um compromisso? Como sobre Delphi Prism? É Delphi no VS2008. Claro, você ainda tem Delphi e, portanto, Codegear, mas você também tem VS (como sua empresa espera que você).

Answer 8

Houve um relatório científico de uma transformação bem sucedida de um 1,5 milhão linha Delphi projeto para C # por John Brant, Don Roberts et al. Ele escreveu um analisador Delphi, um gerador de C # e um monte de regras de transformação na AST. alargar progressivamente o conjunto de regras, fazendo uma compilação diária, os lotes de testes de unidade, e alguns reescrita de partes difíceis Delphi permitiu-lhe com uma equipe de 4, entre os quais alguns dos desenvolvedores originais, com Delphi e C # profundo conhecimento, para migrar o software em 18 meses. John Brant e Don Roberts sendo os desenvolvedores originais do navegador refatoração eo kit de construção de compiladores SmaCC, é improvável que você será capaz de ir tão rápido.

Embora este foi um investimento significativo, é nada 'do mesmo tamanho que o desenvolvimento original'. Os autores observam que uma reescrita simples, sem ferramentas ou com uma ferramenta de um único tiro, como observado por Jeroen, é muito provável que resulte em que, especialmente se os novos requisitos são tidos em conta.

Os autores fizeram refatorações de grande escala durante a sua estada na mesma plataforma para um projeto diferente, substituindo completamente a infra-estrutura de persistência. Isto poderia ser relevante para idosos (BDE?) Projetos baseados.

Answer 9

Somente você pode realmente decidir se um pedaço por pedaço abordagem é possível. Por exemplo pode a aplicação ser dividido facilmente ou são todos os formulários com muita força, juntamente com toda a lógica do negócio. Tecnicamente é possível, mas tudo depende de como a base de código é estruturado realmente.