É possível executar um aplicativo .NET 4.5 no XP?

86

Primeiro, li o seguinte:

Então, desde o último marcador, eu realmente acho que não há maneira de contornar isso, mas eu tinha que ver se conseguia uma resposta definitiva, pois minha equipe gostaria de atualizar do .NET 4.0 para o .NET 4.5. No entanto, temos que oferecer suporte ao XP.

Não há possibilidade de ir para o .NET 4.5 se quisermos oferecer suporte ao XP?

A única coisa em que consegui pensar é em criar duas soluções separadas, mas as bases de código teriam que divergir se usássemos os recursos do .NET 4.5.

Portanto, estou procurando uma solução alternativa incrível que não consegui encontrar e que outras talvez já conheçam.

c# .net .net-4.0 compatibility .net-4.5 Justin Pihony
fonte
9
Não, você não pode. Fique com o 4.0 até que o XP morra definitivamente.
Federico Berasategui

Respostas:

188

Hesito em postar esta resposta, na verdade é tecnicamente possível, mas não funciona muito bem na prática. Os números de versão do CLR e os assemblies da estrutura principal não foram alterados na 4.5. Você ainda tem como alvo a v4.0.30319 do CLR e os números da versão do assembly da estrutura ainda são 4.0.0.0. A única coisa que é distintiva sobre o manifesto do assembly quando você olha para ele com um desmontador como ildasm.exe é a presença de um atributo [TargetFramework] que diz que 4.5 é necessário, que teria que ser alterado. Na verdade, não é tão fácil, ele é emitido pelo compilador.

A maior diferença não é tão visível, a Microsoft fez uma alteração há muito esperada no cabeçalho executável dos assemblies. Que especifica com qual versão do Windows o executável é compatível. O XP pertence a uma geração anterior do Windows, iniciada com o Windows 2000. Seu número de versão principal é 5. O Vista foi o início da geração atual, a versão principal número 6.

Os compiladores .NET sempre especificaram o número de versão mínimo como 4,00, a versão do Windows NT e do Windows 9x. Você pode ver isso executando dumpbin.exe / headers no assembly. A saída de amostra é semelhante a esta:

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            ...
            4.00 operating system version
            0.00 image version
            4.00 subsystem version              // <=== here!!
               0 Win32 version
            ...

O que há de novo no .NET 4.5 é que os compiladores mudam essa versão do subsistema para 6.00. Uma mudança que estava vencida em grande parte porque o Windows dá atenção a esse número, além de apenas verificar se é pequeno o suficiente. Ele também ativa os recursos appcompat, pois assume que o programa foi escrito para funcionar em versões antigas do Windows. Esses recursos causam problemas, especialmente a forma como o Windows fica sobre o tamanho de uma janela no Aero. Ele para de mentir sobre as bordas grossas de uma janela do Aero quando pode ver que o programa foi projetado para ser executado em uma versão do Windows que tem o Aero.

Você pode alterar esse número de versão e defini-lo de volta para 4.00 executando Editbin.exe em seus assemblies com a opção / subsystem. Esta resposta mostra um exemplo de evento postbuild.

No entanto, é aí que termina a boa notícia: um problema significativo é que o .NET 4.5 não é muito compatível com o .NET 4.0. De longe, o maior obstáculo é que as classes foram movidas de uma montagem para outra. Mais notavelmente, isso aconteceu para o atributo [Extension]. Anteriormente em System.Core.dll, ele foi movido para Mscorlib.dll no .NET 4.5. Isso é um kaboom no XP se você declarar seus próprios métodos de extensão, seu programa diz para procurar em Mscorlib pelo atributo, ativado por um atributo [TypeForwardedTo] na versão .NET 4.5 do assembly de referência System.Core. Mas não está lá quando você executa seu programa no .NET 4.0

E, claro, não há nada que o ajude a parar de usar classes e métodos que estão disponíveis apenas no .NET 4.5. Ao fazer isso, seu programa irá falhar com uma TypeLoadException ou MissingMethodException quando executado em 4.0

Apenas mire 4.0 e todos esses problemas desaparecerão. Ou quebre esse impasse e pare de apoiar o XP, uma decisão de negócios que os programadores não podem tomar com frequência, mas certamente podem encorajar, apontando os aborrecimentos que ela está causando. É claro que há um custo diferente de zero em ter que dar suporte a sistemas operacionais antigos, apenas o esforço de teste é substancial. Um custo que nem sempre é reconhecido pelo gerenciamento, a compatibilidade do Windows é lendária, a menos que seja indicada a eles. Encaminhe esse custo para o cliente e ele tenderá a tomar a decisão certa muito mais rápido :) Mas não podemos ajudá-lo com isso.

Hans Passant
fonte
2
Obrigado Hans, percebi que houve algumas alterações importantes. Agradeço a solução alternativa também. Não podemos aceitar pelos motivos que especificou, mas é bom saber. Talvez o XP vá embora para sempre algum dia ...
Justin Pihony
3
just the testing effort is substantial- foi isso que fez nosso gerenciamento "permitir a queda do suporte ao XP".
Christoph Fink,
Eu sei que esta é uma postagem antiga - mas - @JustinPihony: Sua empresa já pensou em instalar um sistema operacional posterior e depois instalar o VMWare ou o Virtual Box? É um pouco tarde para o Windows 7 - mas a Microsoft ofereceu uma instalação virtual do Windows XP que permitia alternar entre 7 e XP. Apenas um pensamento. :-)
Mark Manning
@MarkManning não estava em nosso controle. Estava sendo usado em outro lugar.
Justin Pihony
1
@JustinPihony: Ah. Hmmmmm ...... Minha única outra sugestão é um kluge. Capture a versão do SO e, em seguida, configure todas as funções em suas classes para serem colocadas em matrizes (ou uma matriz). Faça com que um array (ou parte de um array) seja para XP e o outro para sistemas operacionais mais recentes. Então, tudo que você precisa é algum tipo de variável global que é usada para denotar qual conjunto usar. As chamadas podem ser todas iguais (ou ter a mesma aparência), mas um conjunto usa NET40_ <FUNCTION> e os outros podem usar NET45_ <FUNCTION>. Esta seria uma chamada indireta para a própria função. Isso faz sentido?
Mark Manning
21

Infelizmente, não, você não pode executar programas 4.5 no XP.

E a postagem relevante dessa página do Connect:

Postado pela Microsoft em 23/03/2012 às 10:39
Obrigado pelo relatório. Esse comportamento é próprio do projeto no .NET Framework 4.5 Beta. Os sistemas operacionais mínimos com suporte são Windows 7, Windows Server 2008 SP2 e Windows Server 2008 R2 SP1. O Windows XP não é um sistema operacional com suporte para a versão Beta.

Oztaco - Reintegrar Monica C.
fonte
8

O projeto Mono abandonou o suporte ao Windows XP e "esqueceu" de mencioná-lo. Embora eles ainda afirmem que o Windows XP SP2 é a versão mínima com suporte, na verdade é o Windows Vista.

A última versão do Mono para oferecer suporte ao Windows XP foi 3.2.3.

hóspede
fonte
7

Experimente mono:

http://www.go-mono.com/mono-downloads/download.html

Este download funciona em todas as versões do Windows XP, 2003, Vista e Windows 7.

luiseduardohd
fonte
2
O Mono é mais lento do que o .NET e, embora tenha a maioria dos recursos do .NET 4.5, carece de alguns componentes principais, como o WPF ( mono-project.com/Compatibility ). Portanto, você pode usar o suporte Mono para XP se ele fornecer tudo o que você precisa e se estiver de acordo com as implicações de desempenho. No lado positivo, não deve haver necessidade de criar uma "compilação Mono" especial, a compilação .NET 4.5 normal normalmente funciona no Mono, mas você precisa testar com o Mono especificamente para garantir que seja compatível.
Qwertie
2
Tentei mono-3.12.1-gtksharp-2.12.26-win32-0.msi no Windows XP SP3 e falhou com "mono.exe não é um aplicativo Win32 válido" . Também tentei mono-3.0.10-gtksharp-2.12.11-win32-0.exe que falhou com "mono.exe - Ponto de entrada não encontrado. O ponto de entrada do procedimento InterlockedCompareExchange64 não pôde ser localizado na biblioteca de vínculo dinâmico KERNEL32 .dll " .
Cristian Ciupitu,