I was using Chilkat to sign xml messages, very similar to one of your examples:  https://www.example-code.com/dotnet-core/fatturapa_cades_bes.asp

The code was deployed as an Azure V2 function written in .Net Core 2.2

It worked without problems for months, but then after one deploy last week it started crashing on the line:

new Chilkat.Global().UnlockBundle(ChilkatKey);

It works locally, and only fails in production environment, with the exception:

Unable to load DLL 'chilkatDnCore-9_5_0' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
System.DllNotFoundException : Unable to load DLL 'chilkatDnCore-9_5_0' or one of its dependencies: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Chilkat.Global.CkGlobalU_CreateW()

Chilkat is installed into the project as ChilkatDnCore NuGet package version 9.5.0.79, and I have also tried updating to version 9.5.0.80, but nothing changed.

There are two DLLs for Chilkat .NET Core.  One is the 100% managed DLL containing the interface that your application directly uses.  It is just a managed wrapper that calls into a native DLL.   The 2nd is the native DLL.  It is located here:  https://www.nuget.org/packages/ChilkatNativeLib/

The problem is that the .NET Core runtime in the Azure V2 function environment cannot locate the native DLL.

The Chilkat .NET Core class library ( https://www.nuget.org/packages/ChilkatDnCore/ ) makes calls to the ChilkatNativeLib native DLL ( https://www.nuget.org/packages/ChilkatNativeLib/ ) via P/Invoke.
See https://docs.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke

The native library (DLL) is referenced by DllImport statements such as this:

        [DllImport("chilkatDnCore-9_5_0", EntryPoint = "CkGlobalU_CreateW", CharSet = CharSet.Unicode)]
        private static extern System.IntPtr CkGlobalU_CreateW();

The name of the DLL is highlighted in red above.  This DLL (chilkatDnCore-9_5_0.dll) is contained in the ChilkatNativeLib NuGet package.

It’s the native Win32 DLL loading rules that govern things. The P/Invoke marshaller just calls LoadLibrary.

The directories searched for the DLL are described in detail here:
https://stackoverflow.com/questions/8836093/how-can-i-specify-a-dllimport-path-at-runtime/8861895
and also here:
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order?redirectedfrom=MSDN