windows 8

How to solve „An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)“ on Windows 8

Are you a software developer and ever got this message when testing your .NET 2.0 WinForms application on Windows 8?

An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)

An app on your PC needs the following Windows feature: .NET Framework 3.5 (includes .NET 2.0 and 3.0)

Even though your application would run on .NET 4, too?

Here is my story on why this happended to me and how to solve.

Why this happens

When you run a .NET application, Windows 8 seems to check whether the required .NET Framework is available. If it is not available, the above message is being displayed.

How to solve it

Windows 8 cannot know whether your application, compiled for .NET 2, also runs on .NET 4. It has the following knowledge:

  • The .NET Framework you compiled your application for
  • The processor bitness you compiled your application for (i.e. „x86“ or „Any CPU“)

If you want Windows 8 to be aware of anything other, you have to tell. To change the .NET Framework version, I created a configuration file with the same name as the application, in the same folder.

E.g. if your application is „my-app.exe“, your configuration file has to be „my-app.exe.config“. I use the following content of the file:

<?xml version="1.0"?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0.50727"/>
        <supportedRuntime version="v4.0"/>
    </startup>
</configuration>

I.e. you have to tell the supported runtime.

This is sometimes not enough, though. In my scenario, I had the application compiled as „Any CPU“ and configured for V2.0.50727 and v4.0 but still the above Windows message appeared.

My mistake was that on the test system, I only had a 32 bit V2.0.50727, not 64-bit, although the Windows itself was 64-bit. (I don’t know whether a 64-bit version of the .NET Framework exists at all)

So to solve this, I re-compiled the application to „x86“ and then, everything worked perfectly.

(Please correct me if any of my technical assumptions above are wrong)

Fixing „A dynamic link library (DLL) initialization routine failed.“ error on Windows 8

Just fixed an issue with our Zeta Producer 11 that occurs only on the brand new Windows 8. The German error message was:

Die Datei oder Assembly „ZetaHtmlTidy.dll“ oder eine Abhängigkeit davon wurde nicht gefunden. Eine DLL-Initialisierungsroutine ist fehlgeschlagen. (Ausnahme von HRESULT: 0x8007045A)

Translated to English it was:

System.IO.FileLoadException ‚A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)‘

The DLL in concern was a mixed Managed/Unmanaged C++ assembly that wrapped the popular HTML Tidy C sources into a .NET-usable assembly.

So my first idea was that some CRT DLLs were missing:

  • msvcm90.dll
  • msvcp90.dll
  • msvcr90.dll
  • Microsoft.VC90.CRT.manifest

But all were present, even the well-known Dependency Walker/Viewer did not help any further.

Since version 10 of our application worked and version 11 did not work and brought the above error, I was clueless. The main difference was:

  • Version 10 was installed into „C:\Program Files (x86)\Zeta Producer 10“.
  • Version 11 was installed into „C:\Users\YourName\AppData\Local\Zeta Producer 11″ (to bypass administrative setup permissions).

When I moved Version 10 also below the „C:\Users\…“ folder, the error also occurred!

So the cause was not a missing assembly but some kind of (weird?) policy thing.

Some further digging/googling finally lead to the solution on Stack Overflow. The solution was to add some more App.config settings.

My previous, non-working App.config file contained:

<startup>
    <supportedRuntime version="v2.0.50727"/>
    <supportedRuntime version="v4.0"/>
</startup>

My new, working App.config file was:

<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v2.0.50727"/>
    <supportedRuntime version="v4.0"/>
</startup>

So it seems that setting „useLegacyV2RuntimeActivationPolicy“ to „true“ finally switched something to allow for loading mixed-mode DLLs from local folders. Doh!