Hi Rick,

Recently started using the hashword functions in wwEncryption live. A few users (2-4 a day out of 30) are getting the error "Unable to load wwDotNetBridge: Unable to load Clr Instance." from WWDOTNETBRIDGE.INIT.

I looked at your release from last week and it mentions improvements in the .net loader. My first thought is to load that as it seems from what you said that the improvements also provide better error reporting back on a failure.

Questions:

• are all the changes related to loading in the wwDotNetBridge.dll (such that I can just update that dll)?
• any other suggestions to trace this?

Note: I am using the function as part of their login process to compute a hash and if the user just retries, they get in on the second time; and the class was not failing to instantiate previously when I was using it for general encryption services.

Thanks, Albert

Most loader errors are caused either:

• DLL blocked (if downloaded and installed from a zip file)
• Permissions (running off a network drive and not setting up configuration for it)
• Missing DLLs
• .NET 4.5+ not installed

more info here

+++ Rick ---

Thanks. The errors went away after loading your latest build. Maybe I just did something right this time when loading it. I have not put an MyApp.exe.config file on their server - I am not getting a security error at this time.

In case I need to do so, I take it this is just a plain text file with the xml code in it and I do not have to do any "registering" (or whatever) for this .config file.

Albert

No you don't need to register anything.

Most likely you had a blocked file or missing DLLs before. Adding the .config file is a good idea if using anything .NET as it makes sure the .NET bits run under the same security context as a regular Win32 app would run normally. It basically removes the concept of .NET Security Zones (same as IE zones) which is a pain in the ass to deal with without that setting. Usually this affects only file/network access, but there are other things as well.

For this reason I recommend always adding the .config file with your application and also explicitly adding the minimum version of .NET that your application expects so that when the app starts the app fails to load right at the start and lets you know what the problem is.

+++ Rick ---

Have added the .config file. Since I have not used a .config file for anything before, is this something specific to just .net or is it more of a general "Windows thing" that when Windows loads an exe and sees the .config, it loads the settings from it as well? Just so I understand better what I am doing...

Also, you mention adding a tag for minimum .net version - could not find the syntax for this in your docs. And I assume that the minimum should be 4.5.

Thanks, Albert

The .exe.config file is a .NET thing. .NET looks for config files that match the executable when the .NET Runtime starts up for a host process and uses those settings for the lifetime of the application.

.NET has different runtime behavior than standard Windows Win32/64 apps and this config setting sets up the security environment to match what Windows uses natively basically removing the Code Access Security zone checks that .NET uses by default. In general, any app that uses .NET should probably add a .config file that removes the network limitations.

+++ Rick ---