Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficult to get WebP to run: 2nd because of C not executing on UNC path #258

Open
iJungleboy opened this issue Jun 11, 2020 · 1 comment

Comments

@iJungleboy
Copy link

I wanted to share this for others having this problem, or for @lilith who may find another better way to solve this, also in light of the much anticipated ImageFlow.

We make a Plugin for DNN called 2sxc. It is actually a bundle of plugins, one of which is a DNN wrapper containing the resizer. The latest version of the wrapper now automatically enables WebP support.

When we got done developing it, we deployed it on various servers - some of which worked, and others simply failed. After many hours of research we found 2 issues - here's 2nd (see 1st here):

libwebp.dll isn't executed on UNC Path

We use a very flexible hosting setup where the files are on one server and the IIS is basically a very light machine - easy to replace and easy to farm-out. That means our access to the .net solution (DNN in this case) uses UNC like \\server\projects\project 1\web\....

It turns out that our IIS or our .net refused to find or run the libwebp.dll in this path. As soon as we moved the files to a local drive it worked.

Workaround: We just placed libwebp.dll on our webservers on a c:\ drive and added the location to the global PATH. `

I don't really know what causes this or if the behavior can be changed. I also don't know if the reason is IIS / W3C or if it's .net code calling unmanaged code. But I believe this will be important or even critical for the success of ImageFlow in enterprise scenarios.

@lilith
Copy link
Member

lilith commented Jul 30, 2020

Imageflow uses LoadLibrary differently, so this may not be a problem in the future. Would you be willing to see if Imageflow.Net behaves correctly in your scenario? It's a .NET Standard lib. You can call new Imageflow.Bindings.JobContext().GetVersionInfo() to see if everything is loaded right.

If Imageflow.Net is behaving in your scenario, then I will just copy that newer library loading class for the next WebP release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants