Fixing wwDotnetBridge "Unable to load Clr Instance" Errors

In recent weeks a few people have run into the Cannot load CLR Instance error when trying to use the wwDotnetBridge class from Visual FoxPro. The cause for this problem is a security issue in Windows and some new security features in .NET 4.0 when running under User Account Control (UAC) in Windows.

The Problem

wwDotnetBridge is distributed as part of a simple .Zip archive - you download a .zip file and copy the files to your local machine. Unfortunately Windows recognizes that .zip files out of the Downloads folder contain 'downloaded' files and so adds some additional security flags onto files copied to the local machine. These security attributes cause a problem when trying to load the dll.

If you now try the simplest thing possible:

DO wwDotnetBridge
loBridge = CREATEOBJECT("wwDotnetBridge","V4")
? loBridge.GetDotnetVersion()

you'll find that you get an error Unable to load wwDotnetBridge: Unable to load Clr Instance. 0x80131515.

in this code:

*** Fail creation if the object couldn't be created
IF ISNULL(this.Load())
   ERROR "Unable to load wwDotNetBridge: " + this.cErrorMsg
   RETURN .F.
ENDIF

However, if you try to load "V2" of the runtime you'll find that the DLL loads just fine.

Unblocking the DLL

Luckily the solution to this problem is generally quite simple. You simply need to unblock the DLL. To do so:

• Open Explorer
• Find wwDotnetBridge.dll
• Right click and select Properties
• Click the Unblock button

Here's what the dialog looks like:

Distributing your App and avoiding Unblocking

It would really suck if these steps had to be done with a distributed application. But fortunately this problem pops up only if the DLL originated from an Internet Download either as the file directly or as part of a zip that just copied the file to the hard disk. These specific steps of actions effectively mark the DLL as suspicious code which is the cause for the error.

For your final deployed applications however, this shouldn't be an issue. If you install your application using a Windows installer or other process that runs as an Administrative task (ie. permissions were elavated as they are for software installations typically) the DLL file gets properly installed and you will never see this issue pop up.

Unfortunately this is a bummer for development and people trying for the first time to use wwDotnetBridge because the component is shipped as part of a .Zip file that is likely downloaded. So a large chunk of developers are likely to see an issue with this.

Other load Problems

Note while Windows blocking likely is the most common problem, there can be other things that cause problems. Loading from network shares is problematic for example, unless you either provide custom policy settings or a configuration file setting. You can find out more in the helpfile on how to run wwDotnetBridge or any other .NET assemblies from a network location.

• Loading Assemblies from Network Locations

Remember me, Remember me, Remember me

I'm hoping that this blog post will make the issue at least a bit easier to search for, since the solution is typically relatively simple.

Here's a funny anecdote about this error: I had run into this problem before, and actually had spent the time to add some documentation in this regard into the help file. In fact, if you look at the wwDotnetBridge topic in the help file - in the remarks on the bottom -  you'll see this issue addressed along with a detailed link to more info. I however had forgotten about the whole issue, so last week I've been going back and forth with two developers who were running into this problem. Not only that but I couldn't duplicate it, because my copy of wwDotnetBridge.dll isn't copied from a downloaded .zip file and I typically run as an Administrator. Only when I looked up the error code and found out the security issue and reference to unblocking did I finally remember that I solved this problem before :-)

So, yes, writing it down again is probably a good idea.