Why is Windows 8 Compatibility Shim Wrongly Detecting that.Net 3.5 is Required after Install?

Question

I've got a product that we've developed, and we're just testing on Windows 8 and Server 2012. The problem is, after installation on Win 8 / 2012 finishes, a compatibility shim (from what I understand so far) pops up a dialogue saying that the application requires .Net 3.5 to run properly. See the screenshot below:

Since our product is a native printer driver, I find that highly unlikely! It's only pre-requisite for Win 8 / 2012 is a version of the visual c++ re-distributable.

I'm also using install shield 2010 to create the installer if it helps.

Has anyone else seen Win 8 incorrectly suggesting applications require .net 3.5? Does anyone know of any reliable source which defines how the compatibility shim determines whether an application requires .net 3.5?

Thanks!

Andy

** Update **

Found this msdn blog post: http://blogs.technet.com/b/askcore/archive/2012/05/14/windows-8-and-net-framework-3-5.aspx. It suggests in brief, that the dialog can be triggered by the following:

• You attempt to install .Net 2.0, 3.0, or 3.5 using a redistributable package available for download from Microsoft.
• An application attempts to install one of the redistributable packages for a required version during its own installation process.
• An application that requires a legacy version, executes without preinstalling the required version.

Unfortunately, none of this seem to explain why I'm seeing it!

** Update **

Just to be explicit, I have no managed libraries or exes, just pure native c and c++, some built with the visual studio compiler (without clr flags) and some with the DDK.

... How embarrassing!...

Answer 1

Well, this is a little bit embarrassing....

...Turns out there was a .net library compiled with CLR 2 which was being run deep within some InstallScript inside the installer. (In my defence, the installer is fairly large!!)

So apologies for anyone thinking this really was a mystery, the dialogue was kinda right! Also, apologies to the guy who guessed right first time and has since deleted his post. It was quite informative on the subject. Feel free to add it back again and I'll mark is as the answer! :)

Andy.

Answer 2

I think you are looking at a false positive. Here's another quote from the blog you linked:

The classic "Your mileage may vary" disclaimer applies here because we really don't know how all applications will react to the shim intercepting the installation attempt. Also, some apps look for the existence of certain files to verify the installation of the desired .Net version. Such app installations may fail if .Net 3.5 was preinstalled because some files previously present on the older versions have been deprecated in Windows 8. We are however testing many frequently used apps, and in some cases introducing pre-app shims if they are detecting .NET inappropriately.

To avoid problems with applications that need it, it is best to enable the new .Net 3.5 feature before installing your app.

Translation: it's a complete hack.

Answer 3

I'm a lot more experienced with the PCA message that triggers on "failed" installations. For those you can definitely make things better by editing the template app manifests in the InstallShield\support folder called setupexe.<level>.manifest (level is invoker or highest or admin), and in these cases you add a supportedOS element for each additional OS you claim to support - such as by adding <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> for Windows 8.

It might be worth starting with that to see if it somehow helps the .NET detection case. I wouldn't hold my breath, but it will help with the scenario where someone hits cancel before completing installation.

(Note that for code that we have tested on a given target OS you should upgrade to a version of InstallShield that was actually tested there, but in many cases, copying the correct supportedOS element will be sufficient.)