Eu estava errado na minha primeira resposta. Minha primeira sugestão para você foi fazer um shim da "versão lie" para sua aplicação. Mas você não pode, porque você está usando um aplicativo de código gerenciado. Eu não estou dizendo que você não pode escrever ganchos de API para aplicativos .NET, mas o suporte a shim appcompat parece ser muito mais spottier para aplicativos gerenciados.
Os shims de aplicativos implementam redirecionamentos de API para que, quando o aplicativo fizer uma determinada chamada de API, ele seja interceptado ou 'seqüestrado' e alguns outros dados sejam retornados para o aplicativo a partir do shim.
The Shim Infrastructure implements a form of application programming interface (API) hooking. Specifically, it leverages the nature of linking to redirect API calls from Windows itself to alternative code—the shim itself.
Na maioria das vezes, você pode criar seus próprios shims com o Application Compatibility Toolkit:
Efazendouma"versão lie" onde o shim está para o aplicativo sobre qual versão está sendo executada é o caso de uso mais comum para shims de appcompat.
Como os desenvolvedores insistem em fazer verificações de versão no código, o que está errado. A Microsoft diz que está errado. Não faça verificações de versão no seu código. (Em vez disso, verifique a existência ou a falta dela de um recurso específico que você pretende usar.)
Mas os desenvolvedores ainda fazem verificações de versão todos os dias. O pior é que eles fazem verificações de versão "==" em que o aplicativo simplesmente não funcionará, a menos que você esteja executando uma versão
Suspiro ... desenvolvedores.
Chris Jackson, da Microsoft, trabalhou na compatibilidade de aplicativos por muitos anos e suas atitudes são semelhantes:
One of the classes of shims that people find the easiest to understand are the version lie shims. In essence, we have shims that can compensate for the fact that so many developers' keyboards were shipped with a defective > key (and the failure rate of this key on developer keyboards is astonishing). They work by just returning a different value from the GetVersion(Ex) APIs, depending on which operating system you selected.
Mas infelizmente nesse mesmo artigo , ele nos dá o que acredito ser a informação crítica aqui:
OK, so now that you have CompatAdmin started, under the System Database, expand the Compatibility Fixes list. With the /x switch, you'll notice that the WinXPSP2VersionLie now has a plus sign - if you expand this, you'll see a list of modules that have a red diamond next to them. These are modules that this shim specifically excludes. Among these? The .NET Framework modules.
You see, the .NET Framework doesn't take too kindly to being lied to. They do version checks to determine how to implement certain things, and thinking they're running down-level isn't so great. So, we intentionally exclude these modules, and, consequently, we intentionally exclude the code that you're writing that these modules are JITting and executing. Not that we wanted to do so, but the infrastructure didn't give us a great way to separate these out. We either lied to everything, or we lied to nothing. It was worse to lie to everything, so we didn't.
Hehe, é meio engraçado que o .NET esteja fazendo verificações de versão também quando eu disse o quão ruim era uma idéia ...
For real-life applications that need a version lie, well, if the application is managed, you'll have to change the code. This is something you can't, and shouldn't, shim up.
So, if you notice the version lie isn't working, and the application is managed, then my spidey sense tells me you're trying to shim it up with an XP version lie - and that's not going to work.
De MSDN :
Generally, apps should not perform operating system version checks. If an app needs a specific feature, it is preferable to try to find the feature, and fail only if the needed feature is missing.