Missing vcruntime140.dll and vcruntime140_1.dll dependencies

[Joshua-Palamuttam]

Hey all,
I recently used BlingFire in a C# project using the BlingFireNuget version 0.1.8

When deploying that code to an Azure Cloud Service instance the package would throw an error saying "Unable to load DLL 'blingfiretokdll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)".

After some time investigating using DependencyWalker and the process explorer within the Cloud Service instance itself (using an RDP).

We found that the program using BlingFire has a dependency on the following packages vcruntime140.dll and vcruntime140_1.dll. And for now it seems it is entirely dependant on if those two dll's are found in the System32 folder which is managed by Azure itself.

I think the BlingFireNuget will need to add these two dll's can be found here (I believe). These two dll's are the C++ runtime library if that helps at all.

[theolivenbaum]

Instead of adding the DLLs, could you compile the package to be independent of the runtime?

[kganesan1]

Thanks for the suggestion. Are you suggesting to add the project to our solution and compile it as part of the solution instead of using the NuGet package? Just trying to clarify what the proposal is.

[theolivenbaum]

IMHO, it's always easier when you can consume a single nuget package that contains the compiled binary for each platform - we do something similar with the RocksDB package we distribute: https://github.com/curiosity-ai/rocksdb-sharp

[kganesan1]

For .Net SDK or .Net core, we expect it to be part of the system. For VC runtime, I would assume that same since the system32 directory does contain the runtime dlls. In this case, vcruntime140.dll was found but vcruntime140_1.dll was missing in some of our environments in system32 dir. Since Azure manages them, is this an issue with Azure? If the NUGet carried the missing dll until it is widely available (especially in Azure), it might have mitigated this issue and saved us investigation time. Our workaround was to bin place these Dlls in the app directory. This is temporary fix until we find a better solution for this issue. At this point, I am not sure what the better solution is.