Unable to load CLR Instance Error

If you get the error:

Unable to load wwDotnetBridge: Unable to load Clr Instance. 0x80131515

it means wwDotnetBridge wasn't able to load an instance of the self-hosted .NET runtime.

As of wwDotnetBridge 6.22 we have added an automatic check for blocked DLLs

Blocked .NET DLLs: wwDotnetBridge.dll

The most common problem is that wwDotnetBridge.dll is locked down by Windows as an insecure Dll, if installed from an Internet downloaded .zip file. .NET 4.0 won't load an insecure DLL initially when running under User Account Control (UAC).

You can unblock the DLL right clicking on the file in Explorer and pressing the Unblock button.

On newer versions of Windows 10 you may not have the button but a checkbox instead:

You can also use this Powershell command:

Unblock-File -Path '.\wwdotnetbridge.dll'

Note: You have to restart FoxPro after unblocking the DLL.

Note: As of version 6.22 the wwDotnetBridge will try to automatically unblock the dll before it is loaded. For more info see this blog post.

Why does this happen?

If you installed the wwDotnetBridge zip file directly from an Internet download, wwDotnetBridge.dll might be blocked by Windows. If you are running with User Account Control on, the .NET Runtime will not be allowed to load from loading this file as it is marked to come from the insecure Internet Zone.

Blocking applies only to downloaded DLLs

Windows applies blocking only to executable files downloaded from the Internet either directly or via a containing zip archive (such as wwClient.zip) and .NET respects this blocking by failing to load DLLs that are blocked.

For your own applications, if you install wwDotnetBridge.dll as part as a full installation program, the file will be properly installed and no unblocking is required.

wwDotnetBridge.dll and wwIPstuff.dll not Found

Make sure when you run any code that uses wwDotnetBridge, that wwdotnetbridge.dll and wwipstuff.dll are in your FoxPro path.

If not sure, use an explicit check from your application's startup folder that tells you whether the DLLs are visible:

IF !FILE("wwdotnetbridge.dll") OR !FILE("wwipstuff.dll")
  MessageBox("ERROR: wwdotnetbridge.dll or wwipstuff.dll not found.")

We recommend that if the DLLs are not in your application's or dev environment's root path, you explicitly add the path where those DLLs live to your application like this:

SET PATH TO "<relativePathToDlls>" ADDITIVE

You can also check exactly where your app is finding those DLLS with:

? FULLPATH("wwdotnetbridge.dll")
? FULLPATH("wwipstuff.dll")

Loading from a Network Location

Another problem might be that wwDotnetBridge.dll or any other .NET libraries you might be loading from a network share can fail. The problem is that .NET treats network loaded file as coming from a different low rights Windows Security Zone.

The fix for this problem is to add a MyApp.exe.config or VFP9.exe.config file (in the same folder as the EXE) that includes a Runtime policy to allow loading assemblies from network paths:

      <loadFromRemoteSources enabled="true"/>

This effectively makes networked DLLs behave the same as native Windows executables and simply load.

Note that <loadFromRemoteSources> mechanism only works for .NET 4.x, not .NET 2. .NET 2 requires explicitly setting the runtime policy using the CASPOL tool.

For more info on getting assemblies to load off network locations please check out:

.NET Runtime or requested .NET Runtime Version not installed

Another issue that might cause the runtime to fail to load is, if the .NET runtime is not present or an old or incompatible version is installed.

The latest version of wwDotnetBridge requires:

  • .NET 4.5 or later (Windows 7, Server 2008 R2 and later)

Windows 8 and later and Windows 2012 have compatible runtimes already installed. Windows 7 and Server 2008 require explicit installs of later versions.

You can download the latest version (or any other 4.5+ version) from here:

If you run into problems we highly recommend you install the latest version of .NET Framework available for Windows 7 or Windows Server 2008 R2 and later as this removes any ambiguity about versions. .NET Framework installs are relatively small and in most cases require no reboots (unless they are in use by system services).

Older OS Versions

For older OS versions (Vista, XP, 2008 (original), 2003) we also ship wwdotnetbridge_xp.dll which is compiled with .NET 4.0 and works on these old OS's.

To use it, rename wwdotnetbridge_xp.dll to wwdotnetbridge.dll and replace the newer version. This version will not load .NET 4.5 and later assemblies however, which is why we moved away from this version since many common .NET components require at least .NET 4.5 today. This includes shipped support libraries Markdig (Markdown parsing) and SSH (SFTP), but it will work for wwSMTP emails, JSON serialization and various support functions in Web Connection.

Checking what .NET 4.x Version is Installed

If wwDotnetBridge runs you can also check the version with this code:

DO wwDotnetBridge
loBridge = GetwwDotnetBridge()
? loBridge.GetDotnetVersion()

This will display the full .NET version number as well as the 'simplified' version number (ie. 4.6.1 or 4.7.2).

If wwDotnetBridge doesn't run, you can also check which version is installed, but it's bit tedious and requires a registry check:

.NET 4.0 Client Runtime is not Compatible!

When .NET 4.0 originally shipped it also had a client only library of .NET that is not compatible with wwDotnetBridge. Unfortunately this version is very difficult to test for as it has the same version info as the full .NET 4.0 runtime and installs side by side with the full version. If this version is the only one installed, you will need to install the full version. Again we recommend .NET 4.5 or later (whatever the latest is).

Luckily the Client Runtime is obsolete and has been rotated out of production as later .NET 4.x versions are installed by newer Windows OS versions and Windows Update. Regardless, we recommend you always run the latest .NET Runtime Version available for your OS.

Use our Test Sample

We provide a self-contained test executable that you can run in a self contained folder. It's a precompiled EXE that bundles matched DLLs and tries to load wwDotnetBridge and reports the version. Download and unzip this file into a clean, local drive folder, then make sure you unblock wwdotnetbridge.dll* after downloading as described above.

Check your own Version

If you rather do this yourself with the version you have, you can do this from the FoxPro command window. Note make sure you have a matched set of wwipstuff and wwdotnetbridge.dll and that these DLLs are in your FoxPro Path.

Here are the steps to make sure you have a clean environment:

  • Start a fresh instance of Visual FoxPro IDE
  • SET PATH TO && clear path
  • CD <folderWithwwDotnetBridge\wwIPStuff_samples\wwDotnetBridge>
  • Then run the following code
IF !FILE("wwdotnetbridge.dll") OR !FILE("wwipstuff.dll")
  ? "ERROR: wwdotnetbridge.dll or wwipstuff.dll not found."

DO wwDotnetBridge
loBridge = GetwwDotnetBridge("V4")
? loBridge.GetDotnetVersion()

This is the simplest thing you can do without any external dependencies.

© West Wind Technologies, 1996-2019 • Updated: 09/23/18
Comment or report problem with topic