I was wrong on my first answer. My first suggestion to you was to make a "version lie" shim for your application. But you can't, because you're using a managed code application. I'm not saying you can't write API hooks for .NET applications, but appcompat shim support seems to be a lot spottier for managed apps.
Application shims implement API redirects so that when the application makes a certain API call, it gets intercepted or 'hijacked' and some other data is returned to the application from the shim.
http://technet.microsoft.com/en-us/library/dd837644(v=WS.10).aspx
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.
Most of the time, you can cook up your own shims with the Application Compatibility Toolkit:
http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx
And doing a "version lie" where the shim lies to the application about what version it's running on is the most common use case for appcompat shims.
Because developers insist on doing version checks in their code, which is wrong. Microsoft tells you it's wrong. Do not do version checks in your code. (Instead, check for the existence or lack thereof of a particular feature you intend to use.)
But developers still do version checks every day. What's worse is they do '==' version checks where the app simply won't work unless you're running an exact version of Windows, which is arbitrary and stupid.
Sigh... developers.
Chris Jackson of Microsoft has worked on the application compatibility stuff for many years, and his attitudes are similar:
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.
But unfortunately in that same article, he gives us what I believe is the critical piece of information here:
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, that's kinda' funny that .NET is doing version checks too when I just said how bad of an idea it was...
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.
From 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.
