We run a DNN (formerly dotnetnuke) website and one of the modules uses Aspose for .NET, which requires harfbuzz.dll to be shipped with it so we can support certain characters properly. This is a windows server with ASP.net website. Our deployment process is streamlined so we don’t install modules manually, but we have to intervene because of this one file (harfbuzz.dll). When the automated module installer attempts to extract the zip file containing updated assemblies into the bin folder of the site during deployment, more often than not, harfbuzz is locked (file is in use by another process). We have to recycle the app pool of the site and then proceed with the installation.
I’m really not sure what to do about this yet. We’d like to avoid recycling the entire app pool prior to module upgrades. I think it has to do with native vs. managed assemblies, shadow copying, or something else. Perhaps the bin folder is the wrong place for this file?
In addition, I read elsewhere that for windows platforms we don’t actually need to deploy harfbuzz.dll but we ran into errors without it, so that’s a bit confusing as well. We had to deploy harfbuzz.dll into the bin folder to get things to work.
harfbuzz: v7.0
@patrick.ryan
It sounds like you’re encountering file lock issues with harfbuzz.dll during your automated deployment process for your DNN website. This is a common challenge when dealing with native assemblies in a .NET environment, especially when the application is running and holding a lock on the file.
Cause: The file lock issue arises because the application is actively using harfbuzz.dll, preventing updates during deployment.
Solution: Here are some steps you can take to address this issue:
-
Check for Shadow Copying: Ensure that your application is configured to use shadow copying for assemblies. This allows the application to load a copy of the assembly, which can help avoid file locks during updates. You can enable shadow copying in your web.config file by setting <shadowCopyBinAssemblies> to true.
-
Deploy to a Different Location: Consider deploying harfbuzz.dll to a different folder outside of the bin directory, if possible. You can then load it dynamically at runtime. This way, the main application files can be updated without interference.
-
Use a Pre-Deployment Script: Implement a pre-deployment script that checks for any locks on harfbuzz.dll and attempts to release them before the deployment process begins. This could involve stopping the application temporarily or using tools to unlock the file.
-
App Pool Recycling: While you want to avoid recycling the app pool, it may be necessary to do so as a last resort. You can automate this process in your deployment script to minimize downtime.
-
Logging and Monitoring: Implement logging to track which processes are locking harfbuzz.dll. This can help identify if there are specific operations or requests that are causing the lock.
Next Steps: Follow these steps to mitigate the file lock issues and streamline your deployment process. If you encounter any challenges or need further clarification on any of these points, please reach out for additional assistance.
Thank you for your inquiry, and I look forward to helping you resolve this issue!
@patrick.ryan We will consider introducing a public static method Aspose.Words.Shaping.HarfBuzz.HarfBuzzTextShaperFactory.UnloadNativeLibrary() which will unload harfbuzz.dll.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): WORDSNET-27598
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
@alexey.noskov
Thank you so much. Can you offer an alternative solution or advice on how to approach this issue? for now we’re going to remove harfbuzz from the distribution until we absolutely have to upgrade it, but launching new instances makes this difficult.
@patrick.ryan Unfortunately, currently we cannot suggest you any workaround of the issue. Please accept our apologies for your inconvenience.