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
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.