Modernize Studio
Idioma: Português
Escreva-nos

Aplicações .NET antigas, WinForms e Web Forms, modernizadas

As aplicações escritas para .NET Framework nos anos 2000 e 2010 costumam estar em melhor estado do que as ferramentas em VB6 ou Access, e merecem uma resposta mais cuidada do que uma reescrita total. Determinamos o que pode ser migrado tal como está e o que tem de ser reconstruído, e levamos a aplicação para ASP.NET Core com os mesmos dados e as mesmas regras.

Pedir uma análise gratuita Estimar um preço

Porquê agora

O suporte do .NET Framework 4.6.2 termina a 12/01/2027, e as versões 4.6.1 e anteriores já não têm suporte. O .NET Framework 4.8 e 4.8.1 seguem o ciclo de vida da versão do Windows onde estão instalados, pelo que uma aplicação em 4.8 não corre perigo imediato. Ainda assim, a framework só recebe correções, enquanto as novas bibliotecas, ferramentas e opções de alojamento são feitas para o .NET atual.

O ASP.NET Web Forms só funciona em .NET Framework e não passou para o ASP.NET Core. O Windows Forms funciona no .NET atual, mas continua a ser uma tecnologia de secretária para Windows e não dá aos seus colaboradores acesso pelo browser.

  1. Windows 10Fim do suporte da Microsoft
  2. .NET Framework 4.6.2Fim do suporte da Microsoft

O que modernizamos

Aplicações de secretária e web construídas em .NET Framework, e os serviços à sua volta.

  • Aplicações Windows Forms

    Programas de secretária com grelhas DataGridView, DataSets tipados e TableAdapters, muitas vezes instalados com ClickOnce ou MSI. Passam a aplicações web, ou migram para o .NET atual como programas de secretária quando essa for a melhor opção.

  • Sites ASP.NET Web Forms

    Páginas com ViewState, postbacks, UpdatePanel, GridView e SqlDataSource, master pages e user controls. Reconstruímo-las em ASP.NET Core com Razor Pages, MVC ou Blazor, consoante a aplicação.

  • Acesso a dados

    Código ADO.NET, DataSets tipados, LINQ to SQL, modelos Entity Framework 6 e stored procedures. Se a base de dados estiver bem estruturada, mantemo-la e alteramos apenas o código que comunica com ela.

  • Serviços e integrações

    Serviços web WCF e ASMX, .NET Remoting e serviços do Windows. Passam a APIs REST e a serviços em segundo plano no .NET atual.

  • Autenticação e configuração

    Forms Authentication, o fornecedor ASP.NET Membership, autenticação Windows, definições em web.config e app.config. Utilizadores e funções passam para o ASP.NET Core Identity, ou para o Microsoft Entra ID ou Active Directory se já os utiliza.

  • Relatórios

    Crystal Reports para Visual Studio, relatórios RDLC no ReportViewer e exportações para Excel. Passam a documentos gerados pelo servidor, em PDF ou Excel.

Como fica a versão web

Exemplo ilustrativo, dados fictícios

Um registo de rendas como poderia ser num programa WinForms, e o mesmo registo numa página web.

Arraste o manípulo ou use as setas do teclado.

Para onde vai cada parte

Em .NET Framework: Ecrãs WinForms ou páginas .aspx
Na aplicação web: Razor Pages ou componentes Blazor
Em .NET Framework: Code-behind e event handlers
Na aplicação web: Serviços e controladores cobertos por testes
Em .NET Framework: DataSets tipados, LINQ to SQL
Na aplicação web: Entity Framework Core ou Dapper, sobre a mesma base de dados
Em .NET Framework: Serviços WCF ou ASMX
Na aplicação web: APIs REST em ASP.NET Core
Em .NET Framework: Membership e Forms Authentication
Na aplicação web: ASP.NET Core Identity ou Entra ID
Em .NET Framework: ClickOnce ou MSI em cada computador
Na aplicação web: Um único endereço, aberto no browser

Como decorre a migração

  1. Análise em 48 horas

    Envia-nos a solução com o código-fonte, uma cópia de segurança ou script da base de dados e os ficheiros de configuração sem as palavras-passe de produção. Em 48 horas respondemos com um relatório escrito: o que o programa faz hoje, onde estão os riscos, como se organizaria a versão web, um preço fixo para um módulo-piloto e uma estimativa para o resto. É gratuito e não o compromete a nada.

  2. Módulo-piloto

    Construímos uma parte da aplicação sobre uma cópia dos seus dados reais, normalmente a parte mais usada. Os seus colaboradores trabalham com ela no dia a dia antes de decidir o resto.

  3. Os mesmos dados, os mesmos resultados

    Enviamos os mesmos pedidos e dados à aplicação antiga e à nova e comparamos os resultados, dos campos calculados às respostas das APIs e aos documentos gerados. Cada regra de negócio que encontramos passa também a um teste automático, repetido antes de cada nova versão. Recebe um relatório com o resultado de cada verificação.

  4. 30 dias em paralelo

    Quando a aplicação completa estiver pronta, a aplicação antiga continua em uso ao lado dela durante 30 dias. Qualquer diferença aparece enquanto o programa antigo ainda lá está, e corrigimo-la dentro do preço acordado.

Armadilhas típicas, e como as tratamos

  1. ViewState e lógica de postback

    As páginas Web Forms guardam o estado no ViewState e na Session, e a lógica está repartida entre Page_Load, eventos dos controlos e verificações de IsPostBack. O ASP.NET Core não tem equivalente. Convertemos o ciclo de vida da página em pedidos explícitos, para que cada ação tenha um único ponto de entrada claro.

  2. APIs que já não existem

    Os application domains, o .NET Remoting e o Code Access Security não existem no .NET atual, e algumas APIs compilam mas lançam PlatformNotSupportedException quando são executadas. Procuramo-las no código durante a análise, antes de fixar qualquer preço.

  3. Palavras-passe do Membership

    As contas criadas pelo antigo fornecedor ASP.NET Membership guardam as palavras-passe num formato de hash que o ASP.NET Core Identity não usa. Migramos as contas de forma a que cada pessoa entre com a palavra-passe atual e o hash seja atualizado no primeiro acesso, ou planeamos uma redefinição se as definições antigas o impedirem.

  4. Controlos de terceiros e runtimes de relatórios

    Os conjuntos de controlos para Web Forms e WinForms, como os da Telerik, DevExpress ou Infragistics, e o runtime do Crystal Reports estão ligados a versões específicas da framework. Verificamos versões e licenças e decidimos, controlo a controlo, o que os substitui.

  5. Regras em stored procedures e triggers

    Em muitas aplicações desta época, as verdadeiras regras de negócio estão na base de dados. Se a base de dados se mantiver, esses procedimentos também ficam, e as verificações com os mesmos dados cobrem-nos. Se mudar, migramo-los um a um, de forma deliberada.

  6. Estado guardado em memória

    As aplicações que guardam dados na Session, em variáveis estáticas ou na cache em processo pressupõem um único servidor que nunca reinicia. Tornamos esse estado explícito, para que a nova aplicação possa correr em mais de uma instância e sobreviver a um reinício.

Preço e pagamento

Análise

Gratuita

por escrito, em 48 horas

Módulo-piloto

1000–1500 €

normalmente; 50% no início, 50% na aceitação

Condições de pagamento

Pedimos 50% no arranque e 50% na aceitação. A segunda metade é paga antes da entrada em produção e da entrega do código-fonte. Nos projetos maiores, os pagamentos acompanham as fases acordadas.

A análise é gratuita. Se decidir não avançar, fica com o relatório e não deve nada.

Os preços são fixos e acordados por escrito antes de começarmos. Se o trabalho mudar, enviamos um novo orçamento escrito e só avançamos com a sua aprovação.

Numa migração completa, o nosso objetivo é ficar 40 a 60% abaixo do orçamento habitual de uma agência. É possível porque somos um estúdio pequeno, sem escritórios para pagar nem equipa comercial.

Preços sem IVA.

Estimar o preço

Uma migração real, verificada por testes

A Northwind é a base de dados de exemplo que a Microsoft distribuía com o Access, não um cliente nosso. Migrámos uma cópia pública para SQLite e PostgreSQL, comparámos cada tabela e cada consulta com o original através de testes automáticos e construímos sobre o resultado uma aplicação web funcional. O caso de estudo apresenta os números, e o relatório de equivalência enumera cada verificação.

A Northwind é uma base de dados Access, mas para .NET WinForms e WebForms seguimos o mesmo método: migrar, comparar os resultados com os do original sobre os mesmos dados e manter os dois programas em paralelo.

Ler o caso de estudoAbrir a aplicação web (em inglês)

Relatório de equivalência (em inglês) · Pré-visualização clicável e análise de exemplo (demonstração)

Perguntas frequentes

Temos de reescrever tudo?

Não. As bibliotecas de classes com a lógica de negócio passam muitas vezes para o .NET atual com poucas alterações, e a base de dados normalmente pode ficar. O que mais muda é a interface: as páginas Web Forms e os ecrãs WinForms. A análise separa o que pode ser migrado do que tem de ser reconstruído.

A nossa aplicação WinForms pode continuar a ser um programa de secretária?

Sim. O Windows Forms é suportado no .NET atual, e essa migração prolonga a vida do programa por menos do que custa uma reescrita para a web. Se os utilizadores precisarem de acesso pelo browser ou fora do escritório, a resposta é uma aplicação web. Quando ambas fazem sentido, a análise orçamenta as duas.

A nossa aplicação corre em .NET Framework 4.8. É urgente?

Não por causa do suporte, já que as versões 4.8 e 4.8.1 seguem o ciclo de vida da versão do Windows onde estão instaladas. Os motivos para migrar costumam ser outros: acesso pelo browser, alojamento em Linux, bibliotecas que deixaram de suportar o .NET Framework ou a dificuldade de encontrar programadores de Web Forms.

A migração pode ser feita por fases?

Sim. O ASP.NET Core e a aplicação antiga podem funcionar lado a lado no mesmo endereço, migrando uma área de cada vez. A própria Microsoft descreve esta abordagem gradual para aplicações ASP.NET.

Utilizam ferramentas de atualização automática?

Quando ajudam, por exemplo para atualizar ficheiros de projeto e referências a pacotes. Não decidem como uma página Web Forms deve funcionar em ASP.NET Core, e cada parte convertida é verificada face à aplicação antiga com os mesmos dados, como tudo o resto.

Que base de dados vamos usar?

Normalmente a que já tem, em geral o SQL Server. Mudar de base de dados é uma decisão à parte, e só a recomendamos quando há um motivo claro.

Outros serviços

Todos os serviços

Contacto

Escolha o canal que mais lhe convier. Respondemos por e‑mail, em português, no prazo de um dia útil.

Por e‑mail

riccardo@modernizestudio.com
Escrever um e‑mail

Envie-nos o código-fonte e uma cópia da base de dados com dados de teste, ou uma breve descrição da aplicação. Respondemos no prazo de um dia útil.

Envie-nos o seu ficheiro

Se o programa for em Access, Excel, VB6, Delphi ou numa versão antiga de .NET, recebe uma análise escrita gratuita no prazo de 48 horas após o envio do ficheiro.

  1. Faça uma cópia do ficheiro, se preferir com dados de teste.
  2. Anexe-a ao formulário ou a um e‑mail, de preferência num arquivo protegido por palavra-passe, enviando a palavra-passe à parte. Se o pedir, assinamos antes um acordo de confidencialidade.
  3. Em 48 horas: a análise e um preço fixo para um módulo piloto.
Anexar ao formulárioEnviar por e‑mail

Trabalhamos a partir de Itália.

Enviar uma mensagem

Opcional. Uma base de dados, um livro do Excel, capturas de ecrã ou um caderno de encargos, até 10 MB. Para ficheiros maiores, indique na mensagem uma ligação para os descarregar.

Escreva-nos

O botão abre o seu programa de e‑mail com a mensagem já preparada. Nada é enviado até carregar em «Enviar» nesse programa.

Escreva-nos