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
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.
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.
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.
Make sure when you run any code that uses wwDotnetBridge, that
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.") RETURN ENDIF
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")
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:
<configuration> <runtime> <loadFromRemoteSources enabled="true"/> </runtime> </configuration>
This effectively makes networked DLLs behave the same as native Windows executables and simply load.
<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:
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).
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.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.
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.
If wwDotnetBridge doesn't run, you can also check which version is installed, but it's bit tedious and requires a registry check:
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.
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.
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
- Then run the following code
IF !FILE("wwdotnetbridge.dll") OR !FILE("wwipstuff.dll") ? "ERROR: wwdotnetbridge.dll or wwipstuff.dll not found." RETURN ENDIF DO wwDotnetBridge loBridge = GetwwDotnetBridge("V4") ? loBridge.GetDotnetVersion()
This is the simplest thing you can do without any external dependencies.
Comment or report problem with topic